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ABSTRACT 

Kildall has stated a general data flow analysis 
algorithm which has been applied to several forms of 
classical global program optimization. The algorithm 
operates upon the flow graph of a program, where the nodes 
correspond to basic blocks and the edges represent possible 
program control flows. In order to test the effectiveness 
of this algorithm, a general purpose optimizing module was 
written in XPL which analyzes ALGOL-E programs for constant 
computations, common subexpressions and simplifying formal 
identities. Various node selection algorithms were 
investigated with respect to the convergence rate of the 
algorithm. 
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I. 



INTRODUCTION 



A. BACKGROUND 

The increased use of high level language compilers has 
generated an interest in producing efficient machine 
language code from the high level source language. 
Generally, this interest has resulted in techniques for 
transforming- the original source program to produce an 
equivalent form which is optimized with respect to some 
criteria . 

Machine independent optimization algorithms can be 
divided into two broad subclasses - local and global. 
Basically, the difference is that global techniques take 
into account the overall flow of the program to be optimized 
while local methods do not. Specifically, local techniques 
require that the program to be optimized be partitioned into 
“basic blocks." These blocks are divisions of the program 
which have no transfers into or out of the block except for 
a transfer into an initial element and a transfer out of the 
last element. Each block is then optimized independent of 
the other existing blocks. 

A number of techniques have evolved for analyzing global 
program structure, including recent work by Kildall [30], 
Hecht and Ullman [22], Allen [4], Kennedy [25], Graham and 
Wegman [20]. These techniques analyze global flow by 
representing the program as a directed graph with the nodes 
of the graph corresponding to basic blocks with the edges 
showing possible program control flows. If the ALGOL 
program of Figure 1 is analyzed for redundant calculations, 
local techniques would not detect the obvious redundancy of 
(C + B) in block D because this occurrence of the expression 
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resides in a different block than the previous calculation 
of (B ♦ C) . On the other hand, global flow analysis would 
detect the redundant calculation since (B + C) has been 
computed on all paths to block D. 

An iterative global flow analysis algorithm was 
developed by Kildall [28] that is capable of analyzing any 
program structure. The algorithm propagates data from block 
to block until the propagated data reaches a terminal state. 
This process may necessitate multiple passes through some 
blocks. Kildall has shown that the algorithm is finite and 
will succeed given any order for processing the basic 
blocks. However, using a simulation, Lukasczyk [34] has 
shown that the convergence rate of the algorithm can be 
affected by the order in which the "basic blocks" are 
processed. As one would expect, his simulation further 
indicates that as the number of nodes in a program flow 
graph increases, the method of block selection becomes more 
critical . 

An implementation of the global flow analysis algorithm 
to be presented was originally done by Kildall [30], 
Various improvements in the implementation were made, 
including more complete . data structures for computing flow 
information. The results of Lukasczyk 1 s simulation was then 
compared to the actual results from the implementation. 

B. DEFINITIONS 

In order to examine the global flow analysis algorithm 
stated by Kildall [30], various basic notions need be 
presented. 
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IF X > Y THEN 
BEGIN 

A := B + C; 
Y := X; 

END 

ELSE 

H ;= B + C; 
R ;= C + B; 




FIGURE 1 



AN ALGOL PROGRAM AND ITS FLO WGRAPH 



A directed graph G is a two-tuple (N , E) , where N represents 
the set of "nodes" and E is a subset of N x N called 

"edges." Given an ordered pair of nodes (n , n ) in E, an 

12 

edge is said to "leave" node n and "enter" node n . 

1 2 

Further, n is an "immediate predecessor" of n , and n is 
1 2 2 

an "immediate successor" of n . 

1 

A p rog r am flo w graph G is a three- tuple (N, E, R) , where N 
and E are as above and R is a non-empty subset of N 
containing the entry nodes of G such that there exists a 
path from an entry node to any node in N. 

As stated previously, a program can be partitioned into a 
set of ba s ic blo cks. Each basic block is a program segment 
having no transfers entering or exiting except thru the 
initial and final elements. Basic blocks are represented by 
single nodes in the program flow graph and are hereafter 
referred to as blocks. The edges of the program flow graph 
represent - the possible paths of control flow as directed by 
the program structure. 

In the following discussion, note that for simplicity 
the various pools of information are always associated with 
the node "n." Where this rather informal association 
becomes unclear, particular effort will be made to 
distinguish pools with their associated nodes. 

A current optimizi ng pool (P ) is associated with a 

c 

particular block n and represents the optimizing information 

available at the block, which is iteratively refined during 
the flow analysis. 
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An in£ut Pool (P ) is information which is to be used upon 

i 

entry to a given block n. The optimizing function, defined 

below, uses this pool in its transformation. This 
information is identical to the current optimizing pool of a 
block n, and will be referred to as the input pool to 
increase the clarity of the global flow analysis algorithm 
which is stated below. 

An output pool (P ) is optimizing information created by the 

o 

application of the optimizing function to an input pool for 
a block. Upon exiting a block, this set is present and is 
used in performing the meet operator which is defined below. 

A final optimized pool (P ) is the final optimizing 

information that is distinguished as the meet over all paths 

for a block n . This pool is produced by the global flow 
analysis algorithm for each block. 

A ®.oet operator is a binary operation denoted a. , on P x P 

to P, where P is the set of all possible optimizing pools. 

The operator combines an output pool (P ) for a block n and 

o 

a current optimized pool (P ') of an immediate successor 

c 

block n’ to produce an input pool (P * ) for n'. 

i 

p * < — pa p * 

i o c 

The following properties must hold for all a, b and c in P: 

1) a a a = a (idempotent) 

2) a A b - b A a (communitive) 

3) a A (b A c) = (a A b) A c (associative) 
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The meet operation results in a partial ordering upon the 

optimization elements: a < b if and only if a b = b. 

An optimizing fu nct ion maps an input pool to an output pool 
and must have the homomorphism property: 

f (n, a A b) = f (n, a) A f(n, b) 

for all nodes n in N and input pools a and b in P. P is 

assumed to contain an identity element such that 

1 A a = a for all a in P. 

C. A GLOBAL FLOW ANALYSIS ALGORITHM 

Although a basic familiarization with Kildall's flow 
analysis algorithm [28] is assumed, some fundamental notions 
are presented below for completeness. 

The global flow analysis algorithm, Algorithm Q, of 
Kildall was developed for use in the compile time 
optimization of object code. Kildall [30] has pointed out 
that many techniques have been developed to optimize 
straight line code while others take into account program 
flow branching. The Algorithm Q was designed to permit 
extensions of straight line optimization techniques to the 
global case. 

The Algorithm Q is iterative and may be used on any 
program flow graph. As stated previously, the algorithm 
propagates data from block to block until the propagated 
data reaches a final state for a given block. This final 
state is the "meet over all paths," called the MOP solution, 
for a specified block and provides information with which 
the block can be optimized. 
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Informally the Algorithm Q can be stated as: 

Select a node from the list of nodes to be processed, 
its current pool will be used as input. 

Apply the optimizing function to the input pool and 
produce an output pool. 



For each immediate successor, apply the meet operation 
on the output pool and the successor's current pool. If the 
result is strictly smaller than the successor's current 
pool, then reset the current pool to this result and add the 
successor to the nodes to be processed list. 



A particular form of the Algorithm Q which is 
appropriate for machine implementation is stated below. 



Q 1 [ initialize ] 



Q 2 [ terminate?] 



Q3 [select a node] 



Q4 [apply function] 



initialize the investigation 
list L to the entry node 
L <— [n] 

and set the current pool 

of n to empty. 

P < — 0 
c 

if L is empty then halt, 
otherwise 

let n be an element of 
L, and set 
L <-- L - [n] . 

apply the optimizing function 

to the P of n producing 
c 
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Q5 [ enter nodes] 



Q6 [loop] 



output information P for 

o 

the node n. 

for each n' which 

is an immediate successor of 

n f form P ' < — PAP' 
i o c 

where P * and P * correspond 
i c 

to node n» . If P • < P • 

i c 

and' P ' + P • then set 
i c 

P ' < — P ' 
c i 

and 

L < — L U [n ■ } . 
go to Q3. 



As an example of the Algorithm Q, consider common 
subexpression analysis. The pools are partitions of 
available expressions which are in the same class if they 
are known to have the same value. For example, the result 
of analy2ing the statements 

A := 2 ; 

B := 3; 

C : = A + B ; 



could result in the pool 

{A, 2 1 B, 3 | C, A + B, B + A, 2 + 3, 3 + 2, 5} 

where " | " is the delimiter for the different equivalence 
classes. The meet operator is defined as a simple 
intersection operator upon the partition elements, and the 
optimizing function builds new equivalence classes ' from 
existing equivalence classes, based upon operations at a 
particular node. 
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Upon termination of the Algorithm Q, the final 

optimization pool (P^) for each node can be found by 

selecting the step in which each node was last processed. 

The current pool (P ) at this step will- be the final 

c 

optimizing pool (P^) which can be used in a subsequent pas's 
through the block to perform the actual program 

transformations. 

Consider the ALGOL program of Figure 1. The basic 

blocks are A, B, C and D with the entry node A and 

corresponding initial optimizing pool set to empty. Figure 
2 gives the for the program of Figure 1. Only a single 

pass of each block was required since there are no loops in 

the program flow graph. In general, the algorithm requires 
multiple passes on some blocks to produce the final 

optimizing pool. * A complete and formal discussion of the 
global flow analysis algorithm by Kildall can be found in 
[ 28, 29, 30 ]. 
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NODE 



P 

f 







A 


null 


B 


{x I y 
1 x > y} 


C 


{a, b+c, 
c+b | 

y.- x} 


D 


{a, h, 
b + c , 




c + d | 
7/ x} 



F IGUR E 2 

EXAMPLE OF FINAL POOL CONFIGURATION 
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II. I MPLEMENTATION OF ALGORITljh 2 



A. CONCEPTUAL OVERVIEW 

The original implementation of Algorithm Q was given by 
Kildall [30], and this project is basically an extension of 
Kildall's original efforts. 

Implementation of the global flow analysis algorithm 
consists of three separate modules written in XPL [37], The 
first module, the "Code Synthesis Filter Generator," or 
CSFG, creates tables which are vised by the other two 
modules. A set of procedures known as the "Code Synthesis 
Filter Emitters," CSFE, constitute the second module which 
is used with the XPL skeletal compiler generator. The CSFE 
produces the intermediate language which is to be optimized. 
A particular compiler was implemented using the CSFE for a 
language called ALGOL-E, which is described elsewhere [32], 
The third module implements the global flow analysis 
algorithm itself, and is called the "Code Synthesis Filter," 
or CSF . 

Communication between the CSFE and CSF is through an 
intermediate language which represents a program in Polish 
form. The CSF reads the intermediate language from the 
compiler and flags optimization information, without 
actually performing any program transformations. Figure 3 
outlines the flow of the present three module system. 

The next two sections contain a description of the CSFG 
and CSFE as implemented by Kildall [30]. They are included 
here to ensure the completeness of the later CSF description 
and to simplify the discussion of the CSF module. 
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CSPG 




FIGURE_3 

ORGANIZATION OF THE ALGORITHM Q IMPLEMENTATION 
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1. Code Synthesis Filter Generator i.CSFG}_ 

Primarily, the function of the CSFG is to provide a 
method for generating a customized intermediate language. 
The output of CSFG is a set of tables which define an 
intermediate language, along with an XPL case statement used 
for constant propagation. The CSF and CSFE are driven by 
these tables. The intermediate language takes the form of a 
string of Polish operators and operands, augumented with 
control flow information, which assumes a stack model for 
semantic interpretation. 

The CSFG accepts an intermediate language 

specification determined by the grammar specified in TABLE 
I. There are three parts to the language specification: 

1) <TYPE SPECIFICATION 

2) COPCODE SPECIFICATION 

3) <S IMPLIFICATION SPECIFICATION. 

<TY PE SPECIFICATION is primarily a list of variable 
types. Those followed by an asterisk denote data elements 
that occupy "regions" upon execution (i.e., an array). The 
following types are predeclared: 



1) 


DEFAULT 


- type cannot be categorized. 


2) 


LOC 


- location variable (i.e., address). 


3) 


ENT 


- program entry point or branch 
operation destination point. 


4) 


XIT 


- program branch point. 



An XIT (exit) is the operand of a branch 
instruction while the ENT (entry) type variable is placed in 
the Polish sequence at the destination of a branch. 
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<OPCODE SPECIFICATION gives the descriptive 
characteristics for each operator allowed in the Polish 
string. The following characteristics are generated for 
each OPCODE: 

1) operator name 

2) special attributes of the operator 

3) number of operands necessary 
to perform the operation 

4) type of each operand 

5) the number of operands resulting 
from an operator 

6) type of the resulting operands 
of an operator. 

Special operators (REFER, PASS and TOGGLE) are predefined 
and require a LOC type argument with no resulting operands. 
These operators are used for special purposes discussed in 
Section II. A. 2. 



Special operator attributes aid in the optimization 
process by indicating operators which affect program flow or 
which have special . effects on the execution stack. 
Specifically, these attributes are: 

1) LOAD - results in a fetch from memory. 

The operand must be of type LOC 

(i.e., an address from which to fetch). 

2) STORE - results in a store of the second 
operand into the address specified by the first 
operand. The first operand must be type LOC. 

The stack is cleared of both operands upon 
completion. 
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TABLE I 



GRAMMAR FOP. CSF GENERATION DESCRIPTION LANGUAGE 



<CSF SPEC> ::= CTYPE SPEC> <OPCODE SPEC> 

| <T YPE SPEC> <OPCODE SPEC> 

| <S I MP SPEC> 

<TYPE SPEO ::= CTYPE HEAD> <TYPE ELEMENT> ; 

<TYPE HEAD> ::= <TYPES> 

| CTYPE HEAD> CTYPE ELEMENT> , 

CTYPES> ::= TYPES 



CTYPE ELEMENT> 


• * ' 
• # 


CIDENTIFIEP.> 










CIDENTIFIER> 


* 




COPCODE SPEO 


II 

• • 
• t 


COPCODE HEAD> 


COPCODE 


RULE> 


COPCODE HEAD> 


: : = 


COPCODES> 








1 


COPCODE HE AD> 


COPCODE 


RULE> 


COPCODES> ::= 


OPCODES 






COPCODE RULE> 


• • — 
• • 


COPCODE FORMAT> 





| COPCODE FORMAT> CTYPE> 
| COPCODE FORM AT> * 



COPCODE FORM AT> = COPCODE PARMS> = > 

COPCODE PARMS> ::= COPCODE PARM HEAD> 

1 COPCODE P ARM S> CTYPE> 

| COPCODE P ARMS> * 

COPCODE PARM HEAD> ::= CIDENTIFIER> 

| CIDSNTIFIER> 

| (COPCODE T YPE>) 
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TABLE I (CON'T) 



COPCODE TYPE> ::= LOAD 

| STORE 
| STORET 
| DELETE 
| DUPLIC 
1 CONV 
| COMM 
| EXCH 
| COND 
| UCOND 
| GOSUB 
l RETSUB 

<SI MP SPEC> ::= <SIMP HEAD> <SIMP RULE> ; 

<SIMP HEAD > < S I MP LI F IC A T IONS > 

| <SIMP HEAD> <SIMP RULE> , 

<SIMPLIFICATIOHS> SIMPLIFICATIONS 



<SI M? FORM AT > <IDENTIFIER> 
<SI MP FORM AT> <STRING> 



= < SIMP LEFT PARI> = > 



<SIM P RULS> :: = 

I 

<SI MP FO RM AT> 

<SI MP LEFT PART> 

<SI MP RULE HEAD> 



< S I M P RULE 
| <SIMP RULE 
! <SIMP RULE 

;:= <OPCODE> 

| < SIMP RULE 
| <S IMP RULE 
| <SIMP RULE 



HEAD> <IDENTIFIER> 
HEAD> <STRING> 

H EAD> * 

HEAD> <IDENTIFIER> 
HEAD> <STRING> 
HEAD> * 
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3) S 10 RET - the same as STORE; however, the 
second operand is retained on the stack for 
future use. 

4) DELETE - removes the top entry from the 
stack (i.e., normally an operand). 

5) DUPL IC - duplicates the top entry on the stack. 

6) CONY - type conversion operators. 

7) COMM - operator is communitive in all 
its operands. 

8) EXCH - exchanges top two entries on the stack. 

9) COM2 - conditional branch operator. 

10) UCOND - unconditional branch operator. 

11) GOSUB — branch to a procedure. 

12) RETSUB - return branch from a procedure 
to the calling point. 

SIMPLIFICATION SPECIFICATIONS defines acceptable 
transformations which may be performed on the operators. 
Each transformation is of the form 

1) operator 

2) operands 

3) result operands. 

For example: 



ADD "0" A => A 

indicates that the ADD operator would result in the operand 
A if one operand is zero, where A represents any arbitrary 
expression. 
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TABLE II outlines the particular intermediate 
language description used for the ALGOL-E compiler. TABLE 
III provides the complete output from the CSFG for this 
description. 

2. Code Synthesis Filter Emitters ICSFE). 

The CSFE is a set of XPL procedures that is included 
as an integral part of the XPL skeletal compiler for any 
particular compiler generation. The CSFE uses the tables 
produced by the CSFG to generate the intermediate language 
which is compatible with the optimizer, but tailored to the 
specific source language and compiler being developed. 

As discussed above, the intermediate language is a 
Polish sequence consisting of a string of operators, 
operands, and branch point references. A table of 

referenced constants is also included in the Polish 

sequence. Figure 4 shows the format of the CSFE output. 
Individual fields are: 

1) OFFSET (8b) - used for diagnostic reporting. 

2) OPCODE/TYPE (8b) - designates the opcodes if 

the entry is an operator, or designates 
the type of operand if the entry is an 
operand. 

3) C(1b) - if set, indicates a reference to the 

constant tables; if not, reference is to 

• an address. 

4) ADDR (15b) - address field of operands in the 
intermediate language. 
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TABLE II 



A SAMPLE CSF GENERATOR SPECIFICATION FOR ALGOL-E 



/* SOUTPUT PRINTED TABLES */ 

/* $P3NCH TABLES */ 

TYPES INT,REAL,BOOL,IARRAY*,RARRAY*; 
OPCODES 

TRU (CON V) REAL => INT ' /* 

/* 

RND (CONV) REAL => INT /* 



FLT (CONV) INT => REAL, 

ADD (COMM) INT INT => INT, 

RADD (COMM) REAL REAL => REAL, 
SUB INT INT => INT, 

RSUB REAL REAL => REAL, 

MUL (COMM) INT INT => INT, 

RMUL (COMM) REAL REAL => REAL, 
DIV INT INT => INT, 

RDI V REAL REAL => REAL, 

EXP INT INT => INT, 

RIXP REAL INT => REAL, 

I RXP INT REAL => REAL, 

RRXP REAL REAL => REAL, 



/* 

/* 

/* 

/* 

/* 

/ ★ 
/ • 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 



TRUNCATE TAKES */ 
REAL TO INTEGER */ 
RND IS THE */ 

ROUND OPERATOR */ 

FLT IS THE */ 

FLOAT FUNCTION */ 
INTEGER ADDITION */ 
(COMMUTATIVE) */ 

n n n t s nnfnTnv / 

i.ijnxt n Jdxx lOii •/ 

INTEGER */ 
SUBTRACTION */ 

REAL SUBTRACTION */ 
INTEGER */ 
MULTIPLICATION */ 
REAL SUBTRACTION */ 
INTEGER DIVISION */ 
REAL DIVISION */ 
INTEGER */ 
EXPONENTIATION */ 
REAL TO INTEGER */ 
EXPONENT */ 

INTEGER TO REAL */ 
EXPONENT */ 

REAL TO REAL */ 
EXPONENT */ 
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TABLE II (CON’T) 



LSS 


* * => 


BOOL, 




/* 


LESS .THAN TEST */ 




LEQ 


* * => 


BOOL, 




/* 


LESS THAN OR */ 












/* 


EQUAL TEST */ 




EQL 


(COUM) 


* * = 


> BOOL, 


/* 


EQUAL TO TEST */ 




NEQ 


* * => 


BOOL, 




/* 


NOT EQUAL TO TEST 


V 


GEQ 


* * => 


BOOL, 




/* 


GREATER THAN OR */ 










/* 


EQUAL TO */ 




GTR 


* * => 


BOOL, 




/* 


GREATER THAN TEST 


V 


INEG 


H 

K3 

II 

V 


INT, 




/* 


INTEGER NEGATION 


V 


RNEG 


REAL = 


> REAL, 


/* 


REAL NEGATION */ 




NOT 


BOOL => 


BOOL 


/ 


/* 


BOOLEAN NOT */ 




AND 


(COMM) 


BOOL 


BOOL => BOOL, 


/* 


BOOLEAN AND */ 




BOR 


(COMM) 


BOOL 


300L => BOOL, 


/* 


BOOLEAN OR */ 




LOD 


(LOAD) 


LOC = 


> * / 


/* 


LOAD FROM ADDRESS 


V 


STO 


(STOEST) LOC 


at = S * 

' • , 


/* 


STORE AND RETAIN * 


/ 










/* 


VALUE */ 




STD 


(STORE) 


LOC 


* 

II 

V 

% 


/* 


STORE AND REMOVE * 


/ 










/* 


VALUE */ 




DEL 


(DELETE) * = 


> , 


/* 


DELETE TOP */ 












/* 


ELEMENT */ 




DUP 


(DUPLIC) => 


*, 


/* 


DUPLICATE */ 












/* 


ELEMENT */ 




XCH 


(E XCH) 


= > , 




/* 


EXCHANGE LAST */ 












/* 


ELEMENTS */ 




HLT 


=> / 






/* 


PROGRAM HALT */ 




BRS 


(UCOND) 


XIT 


=> , 


/* 


UNCONDITIONAL */ 












/* 


BRANCH */ 




BSC 


(COND) 


BOOL 


XIT => , 


/* 


CONDITIONAL */ 












/* 


BRANCH V 




NOP 


= > , 






/* 


NO OPERATION */ 
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TABLE II (CON'T) 



PRO (GOSUB) XII => , 

RTN (RETSU3) => , 

GET INT => LOC, 

RET LOC => , 

RRD => REAL, 

IRD => INT, 

BRD => BOOL,- 
WRVx* => , 

DEP => , 

TAB INT => , 

SOP * => ; 
SIMPLIFICATIONS 
ADD "0" A => A, 

RADD "0" A => A, 

MUL "0" A => ”0", 
RKUL "0" A => "0", 
MUL "I" A => A, 

RMUL "1" A => A, 

SUB A A => "0", 

RSUB A A => "0", 

DIV ''0'' A => "0" , 
RDI V "0” A => "0" , 
EXP A "0" => "1" , 
RIXP A "0" => "1" , 
IRXP A "0" => "1" , 
RRXP A "O'* => "1" , 
EXP A ”1" => A , 

RIXP A " 1 " => A, 

IRXP A "1" => A, 

RRXP A "1" => A, 



/* PROCEDURE */ 

/* TRANSFER */ 

/* RETURN FROM */ 

/* PROCEDURE */ 

/* GET STORAGE */ 

/* RETURN STORAGE */ 
/* REAL READ */ 

/* INTEGER READ */ 

/* BOOLEAN READ */ 

/* WRITE VARIABLE */ 
/* DUMP BUFFER */ 

/* TABULATE */ 

/* 0<-A=A+0=A */ 

/* 0*A=A*0=0 */ 

/* 1 * A = A* 1 = A */ 

/* A- A= */ 

/* 0/A = 0 */ 

/* 0/A = 0 */ 

/* A**0 = 1 */ 



/* A ** 1 = A V 
/* ft ** 1 = A */ 
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TABLE III 



CSFG OUTPUT FOR ALGOL-E 



DECLARE (MULL, DEFAULT, LOC, ENT, XIT, INT, REAL, BOOL, IARRA 
Y, RARRAY) BIT (8) ; 

DECLARE NTYPES LIT ERALL Y ' 9 ' ; 

DECLARE (REFER, TOGGLE, PASS, TRU, RND, FLT , ADD, RADD, SUB, 
RSUB, MUL, RMUL, DIV, RDIV, EXP, RIXP, IRXP, RRXP, LSS , LEQ, 

EQL, NEQ, GEQ, GTR, INEG, RNEG, NTO, AND, BOR, LOD, STO, ST 

D, DEL, DUP, XCH, HLT , BRS, BSC, NOP, PRO, RTN, GET, RET, HR 

D, IRD , 3RD, WRV , DUP, TAB, SUP) BIT (8) ; 

DECLARE NOPCODES LITERALLY • 50 * ; 

DECLARE OPCODES CHARACTER INITIAL ( 

' NULLDEF AULTLOCENTXITINTREALBOOLIARRAY RARRAYREFERTOGGLEPASST 
RURNDFLTADDRADDSUBRSUBBULRriULDIVRDIVEXPRIXPIRXPXPRRXPLSSLEQE 
QLNEQGEQGTRI NEGRNEGNOTA.NDBORLODSTOSTDDELDUPXCHHLTBRSBSCNOPPR 
ORTNGETRETRRDIRDBRDWRVDMPIABSUP') ; 



DECLARE OPR A NGE (6 0 ) 


BIT (8) 


INITIAL (0, 4, 


11, 14, 17, 


20, 


23, 


27, 31, 37, 43, 48, 


54, 58, 61, 64, 67, 


70, 74, 77, 


81* 


84, 


88, 91, 95, 98, 102, 


106, 


110, 113, 116, 


119, 122, 125, 


128, 


132, 136, 139, 142, 


145, 


148, 151, 154, 


157, 160, 163, 


166 , 


169, 172, 175, 178, 


181, 184, 187, 190, 193, 196, 19 


9* 


202, 


205, 205) ; 

DECLARE OP_TYPE (59) 


BIT (8) 


INITIAL (0 , 0, 


0/ 0/ 0/ 0 f 


o. 


o. 


1, 1/ 0, 0, 0, 7, 7 


, 7, 8 


, 8, 0, 0, 8, 8 


t Of Of 0 1 


0, 0 


* o. 


0, 0, 8, 0, 0, 0, 0, 


0, 0, 


8, 8, 2, 4, 3, 


5, 6 f 9, 


0, 


11* 


10, 0, 12, 1*3 , 0, 0, 


0, 0, 


0, 0, 0, 0, 0) 








DECLARE OP_DEGL ( 59 ) 


BIT (8) 


INITIAL (0, 0, 


Of Of Of Of 


0, 


o* 


0, 0, 0, 0, 0, 1, 1 


, 1, 2 


, 2, t. , 2,. 2 , 2 


f 2 t 2 f 2 t 


2, 2 


, 2, 


2. , 2 , 2/ 2, 2/ 2 j 1/ 


1, 1, 


2 * 2, 1, 2, 2, 


0, 0, 0 


* 1* 


2, 


0/ 0/ 1/ 1/ 0 f 


0, 1, 


o, i, D; 
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TABLE III (CON'T) 



DECLARE OP_DEGR (59 ) BIT(8) INITIAL (0 , 0, 0, 0, 0, 0, 0 



0, 


0/ 0/ Oj 0 g 1 / 1 # 1 1 


1, 1, 1, 1, 1, 1 


, 1, 


1, 1/ 


1, 


If If If If If If If If 


1/ 1/ 1, 1/ o, 0, 


1, 


0, 0, 0 


0, 


Of Of 1/ 0/ 1/ If If 0/ 


0, 0, 0) ; 






DECLARE 0?_I NDEX (60) BIT (8) 


INITIAL (0 , 1, 1, 


1/ 


1, 1, 1 


1, 


1, 1, 1, 1, 1, 3, 5, 7 


, 10, 13, 16, 19, 


22, 


25, 28 


34, 


37, 40, 43, 46, 49, 52, 


55, 58, 61 , 63 , 


65 , 


67, 70, 


75, 


78, 80, 81, 82, 82, 82 


, 83, 85, 85, 86, 


86, 


88, 89 


91, 


92, 93, 93, 94, 95) ; 








DECLARE OP_INFO (170) BIT (16) INITIAL (0, 6 


, 5, 


6, 5, 


5, 


5, 5, 6, 6, 6, 5, 5, 5, 


6, 6, 6, 5, 5, 5, 


6, 


6, 6, 5 


5, 


6, 6, 6, 5, 5, 5, 6, 5, 


6, 5, 6, 6, 6, 6 


, 6, 


1/ 1, 


1, 


7, 1, 1, 7, 1, 1, 7, 1, 


18 7, 1, 1, 7, 5, 


5, 


6, 6, 7 


7, 


7, 7, 7, 7, 7, 2, 1, 2, 


1, 1, 2, 1, 1, 1 


, 4, 


7, 4, 


2, 


2, 6, 5, 7, 1, , 1, 0, 


J, , y , o, z;. 


2 , 


111, 3 


3, 


115, 3, 2, 3, 0, 5, 2, 


2, 0, 5, 2, 2, 0 


, 2, 


2, 3, 


2, 


3, 0, 3, 2, 3, Of 3, 2, 


3, 151, 2, 3, 5, 


155, 


2, 3 


159 


, 2, 3, 5, 163, 2, 3, 5, 


0, 2, 5, 2, 0, 2 


, 5, 


2, 0, 



2, 16 7, 2, 5, 2, 0, 2, 5, 2) ; 

DECLARE SIMP_INDEX (59) BIT (8) INITIAL (0, 0, 0, 0, 0, 

0, 0, 0, 0, 0, 0, 0, 0, 0, 95, 99, 119, 123, 103, 107, 
131 135, 139, 143, 147, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 

0, 08 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 
DECLARE OP_STR (2) CHARACTER INITIALf' 1 , 'O', • 1 • ) ; 

**** ***# $*** *** * **** **** 

DECLARE (NULL, DEFAULT, LOC, ENT, XIT, INT, REAL, BOOL, 
Y, RARRAY) BIT (8) ; 

DECLARE NTYPES LITERALLY' 9* ; 



, o, 
1 , 1 , 
, 0 , 

, 1 , 
, 31, 
73, 
/ 90, 

5, 6, 
/ 5 / 
7, 1, 
, 7, 
4, 5, 
, 2 , 
0 , 2 , 
, 5, 
2, 5, 

0 , 0 , 
127, 
0 , 0 , 
/ 0 ) ; 



IARRA 
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TABLE III (CON'T) 



DECLARE (REFER, TOGGLE, PASS, TRU, RND , FLT , ADD, RADP, SUB, 
RSUB, MUL, RrtUL, DIV, RDIV, EXP, RIXP, IRXP, RRXP, LSS, LEQ, 

EQL, NEQ, GEQ, GTR , INEG, RNEG, NOT, AND, BOR, LOD, STO, ST 

D, DEL, DUP, XCH, HLT , BRS, BSC, NOP, PRO, ETN, GET, RET, RR 

D,- IRD, BED, WRV , DMP , TAB, SUP) BIT (8); 

DECLARE NOPCODES LITERALLY ' 50 • ; 

DECLARE OPCODES CHARACTER INITIAL ( 

' NULLDEF AULT LOCENTXITINTRE A LBOOL I ARRAY R ARRAY REFERTOGGLEP ASST 
RURNDFLT ADDR ADDS UBRSUBMULR MULDIVRDI VEX PRI XPI RXPRRXPLSS LEQSQL 
NEQGEQGTRIN EGRNEGNOT AND30RL0DST0STDDELDUPXCHHLTBRS 3SCH0PPR0R 
TNGETRETRRDIRD3RDWRVDHPTABSUP 1 ) ; 



DECLARE 


OPRANGE (6 


0) 


BIT 


(8) 


INITIAL 


(0, 


4 


9 


11, 


14, 


1 


7, 


20, 


23, 


27, 


31, 


37, 


43 


9 


48, 


54, 


58 


, 61, 


64, 


6 


7, 


70, 


74, 


77 


/ 


8-1, 


84, 




88, 


91 


, 95 


, 9 


8, 


102 


, 1 


06 , 


1 10, 


113 


r 


1 16 


, 119, 


122 


9 


125, 


128 


§ 


132 


, 1 


36, 


139 


/ 


142, 


14 


5, 


14 8, ' 


i q i 

' • 9 


i 


54, 


157 


1 

9 


60, 




163, 


166 


i 


16 


9/ 


172, 


1 75, 


178 


, 1 


81, 


184, 


187 


/ 


190 


, 193, 


196 


9 


199, 


202 


t 


205 


, 2 


08) ; 






























DECLARE 


OP 


_TYPE (59) 


BIT 


(8) 


INITIAL 


(Or 


0 


, o 


, o. 


o. 


o. 


0 


, o. 


1, 


i/ 


o. 


o. 


o. 


7, 


7 / 


7, 


8, 


8, 


0, 0, 


8/ 


8, 


o. 


o. 


0, 


o. 


0, 


0, 


o. 


0 


9 


8/ 


o. 


o. 


o. 


o. 


0, 


o. 


8, 8, 


2, 


4, 


3 , 


5 / 


6, 


9, 


0, 


11, 


10, 


0 


, 1 


2 / 


13, 


08 


o. 


o. 


o. 


o. 


0, 0, 


o. 


0) 


t 












DECLARE 


OP 


_DEGL (5 9) 


BIT 


(8) 


INITIAL 


(0, 


0 


, o 


, o. 


0, 


0, 


0 


, o. 


o. 


0, 


o. 


o. 


0/ 


1, 


1, 


1/ 


2, 


2, 


2, 2, 


2, 


2, 


2, 


2, 


2, 


2, 


2, 


2, 


2, 


2 


, 2 


, 2 


, 2, 


2 1 


1 


, 1, 


1/ 


2 1 


2, 1, 


. 2, 


2 


, 1 


, o. 


o. 


0, 


1 


, 2, 


0, 


1 , 


o. 


1, 


1, 


o. 


0, 


o. 


1/ 


o, 


i,i); 


> 
















DECLARE 


OP 


_DEGR (59) 


BIT 


(8) 


INITIAL 


(0, 


0 


, o 


, o. 


o. 


0, 


0 


, o. 


0, 


0, 


0, 


0, 


o. 


1 , 


1/ 


1, 


1, 


1 , 


i/ i. 


1, 


1/ 


1/ 


1, 


1, 


1, 


If 


1, 


1, 


1 


, 1 


, 1 


, 1, 


1, 


1 


, 1 1 


1 , 


1, 


i, i, 


r 1, 


0 


, 0 


, 1, 


0, 


0, 


0 


, o. 


0, 


0, 


0, 


1, 


0, 


1/ 


1, 


1, 


0, 


o. 


0, 0) ; 


1 

















33 



TABLE III (CON ' T) 



DECLARE OP_INDEX (60) BIT(8) INITIAL (0 , 1, 1, 1, 1 , 1, 1, 1, 
1, 1, 1, 1/ 1/ 1, 3/ 5, 7, 10, 13, 16, 19, 22, 25, 28, 31, 
34, 37, 40, 43, 46, 49, 52, 55, 58, 61, 63, 65, 67, 70, 73, 

75, 78, 80, 81, 82, 82, 82, 83, 85, 85, 86, 86, 88, 89, 90, 

91, 92, 93, 94, 95) ; 

DECLARE OP_I NFO (17 0) BIT(16) INITIAL (0, 6, 5, 6, 5, 5, 6, 

5, 5, 5, 6, 6, 6, 5, 5, 5, 6, 6, 6, 5, 5, 5, 6, 6, 6, 5, 5, 

5, 6,6, 6, 5 / 5 , 0, 5, 6, 3, 6, 6, 6, 6 i 6, 1, 1, 7, 1, 

1, 7, 1, 1, 7, 1, 1, 7, 1, 1, 7, 1, 1, 7, 5, 5, 6, 6, 7, 7, 

7, 7, 7, 7, 7, 7, 2, 1, 2, 1, 1, 2, 1, 1, 1, 4, 7, 4, 4, 5, 

2, 2, 6, 5, 7, 1, 5, 1, 0, 3, 2, 2, 0, 3, 2, 2, 111, 3, 2, 

3, 115, 3, 2, 3, 0, 5, 2, 2, 0, 5, 2, 2, 0, 2, 2, 3, 0, 2, 

2, 3, 0, 3, 2, 3, 0, 3, 2, 3, 151, 2, 3, 5, 155, 2, 3, 5, 

159, 2, 3, 5, 163, 2, 3, 5, 0, 2, 5, 2, 0, 2, 5, 2, 0, 2, 5, 
2, 167, 2, 5, 2, 0, 2, 5, 2) ; 

DECLARE SIKP_INDEX (59) BIT (8) INITIAL (0, 0, 0, 0, 0, 0, 0, 

0, 0, 0, 0, 0, 0, 0, 0, 0, 95, 99, 119, 123, 103, 107,127, 

131, 135, 139, 143, 147, 0, 0, 0, 08 08 0, 0, 0, 0, 0, 0, 0, 

0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 ) ; 

DECLARE OP_STR (2) CHARACTER INITIAL ('», 'O', ' 1 ' ) ; 

/* CASE 0: NULL */ 

» 

/* CASE 1: DEFAULT => (TYPE) */ 

I 

/* CASE 2: LOC => (TYPE) */ 

t 

/* CASE 3: ENT => (TYPE) */ 

f 

/* CASE '4: XIT => (TYPE) */ 

1 

/* CASE 5: INT => (TYPE) */ 
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TABLE III (CON'T) 



/* CASE 6: REAL => (TYPE) */ 

f 

/* CASE 7: BOOL => (TYPE) */ 

t 

/* CASE 8: IAERAY => (TYPE) */ 

t 

/* CASE 9: RARRAY => (TYPE) */ 

m 

t 

/* CASE 9: RARRAY => (TYPE) */ 

0 

t 

/* CASE 10: REFER => (OPCODE) */ 

0 

f 

/* CASE 11: TOGGLE => (OPCODE) */ 

« 

t 

/* CASE 12: PASS => (OPCODE) */ 

» 

/* CASE 13: TRU REAL => INT (OPCODE) */ 

* 

/* CASE 14: RND REAL => INT (OPCODE) */ 

0 

t 

/* CASE 15: FLT INT => REAL (OPCODE) */ 

t 

/* CASE 16: ADD INT INT => INT (OPCODE */ 

* 

/* CASE 17: RADD REAL REAL => REAL (OPCODE) */ 
/* CASE 18: SUB INT INT => INT (OPCODE) */ 

t 

/* CASE 19: RSUB REAL REAL => REAL (OPCODE) */ 

! 

/* CASE 20: MUL INT INT => INT (OPCODE) */' 

0 

t 

/* CASE 21: R MU L REAL REAL => REAL (OPCODE) */ 
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TABLE III (CON'T) 



/* 


CASE 


22: 


DIV 


INT IHT 


= > INT (OPCODE) 


V 




/* 


CASE 


23: 


RDI V 


REAL REAL => REAL 


(OPCODE) */ 




/* 


CASE 


24: 


EXP 


INT INT 


=> INT (OPCODE) 


V 




/* 


CASE 


25: 


RIXP 


REAL INT => REAL 


(OPCODE) */ 




/* 


CASE 


26: 


IRXP 


INT REAL => REAL 


(OPCODE) */ 




/* 


CASE 


27: 


RRXP 


REAL REAL => REAL 


(OPCODE) */ 




/* 


CASE 


28: 


LSS 


DEFAULT 


DEFAULT => 


BOOL 


(OPCODE) 


*/ 


/* 


CASE 


29: 


LEQ 


DEFAULT 


DEFAULT => 


BOOL 


(OPCODE) 


*/ 


/* 


CASE 


30: 


EQL 


DEFAULT 


DEFAULT => 


BOOL 


(OPCODE) 


V 


/* 


CASE 


31: 


NEQ 


DEFAULT 


DEFAULT => 


BOOL 


(OPCODE) 


V 


/* 


CASE 


32: 


GEQ 


DEFAULT 


DEFAULT => 


BOOL 


(OPCODE) 


V 


/* 


CASE 


33: 


GTR 


DEFAULT 


DEFAULT => 


BOOL 


(OPCODE) 


V 


/* 


CASE 


34: 


IN EG 


INT => 


INT (OPCOD 


S) */ 






/* 


CASE 


35: 


R N EG 


REAL => 


REAL (OPCODE) 


V 




/* 


CASE 


36: 


NOT 


BOOL => 


BOOL (OPCODE) 


V 




/* 


CASE 


37: 


AND 


BOOL BOOL => BOOL 


(OPCODE */ 
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TABLE III (CON'T) 



/* 


CASE 38: 


BOR 


/* 


t 

CASE 39: 

• 


LOD 


/* 


f 

CASE 40: 


STO 


/* 


» 

CASE 41: 

# 


STD 


/* 


t 

CASE 42: 


DEL 


/* 


» 

CASE 43: 


DUP 


/* 


« 

CASE 44: 

• 


XCH 


/* 


f 

CASE 45: 


HLT 


/* 


t 

CASE 46: 


BRS 


/* 


• 

CASE 47: 


BSC 


/* 


• 

CASE 48: 


NOP 


/* 


t 

CASE 49: 


PRO 


/* 


• 

CASE 50: 


RTN 


/* 


• 

CASE 51: 

• 


GET 


/* 


» 

CASE 52: 


RET 


/* 


» 

CASE 53: 


RRD 



BOOL BOOL => BOOL (OPCODE */ 
LOC => DEFAULT (OPCODE */ 

LOC DEFAULT => DEFAULT (OPCODE) 
LOC DEFAULT => (OPCODE) */ 
DEFAULT => (OPCODE) */ 

=> DEFAULT (OPCODE) */ 

= > (OPCODE) */ 

=> (OPCODE) */ 

XIT => (OPCODE) */ 

BOOL XIT => (OPCODE) */ 

=> (OPCODE) */ 

XIT => (OPCODE) */ 

= > (OPCODE) */ 

INT => LOC (OPCODE) */ 

LOC => (OPCODE) */ 

=> REAL (OPCODE) */ 



V 
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TABLE III (CON'T) 



/* CASE 54: IRD => INT (OPCODE) */ 

f 

/* CASE 55: BRD => BOOL (OPCODE) */ 

f 

/* CASE 56: WRV DEFAULT => (OPCODE) */ 

« 

» 

/* CASE 57: DMP => (OPCODE) */ 

f 

/* CASE 58: TAB INT => (OPCODE) */ 

» 

/* CASE 59: SUP DEFAULT => (OPCODE) */ 

< » 
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32 BITS 



8b 8b 1b 15b 

OFFSET OP/TYPE C ADDR 



2 

3 



K 



K+1 



►K+2 





































XIT 




K + 2 












































ENT 




0 




FIG(JRE_4 

INTERMEDIATE LANGUAGE OUTPUT FORMAT FROM CSFE 
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The CONSTANT TABLE be 
of constants. An entry then 

BYTE i8b}. 

0 

1 

2-3 
4 + i 



gins with a count of the number 
follows for each constant as: 

CONTEND 

•number of characters for the 
constant 

type of constant 
address assigned to the 
constant 

character string of length 
i representing the constant. 



The basic CSFE procedures are as listed with calling 
values of: 

o - operator 
t - type 

s - character string 

14 

x - integer constant 0 < x < 2 

1) EMITO(o) - places a reference to an 
operator in the Polish sequence. 

2) EMITC (s , t) - places a reference to the 
constant string s of type t into the Polish 
sequence. 

3) EMIT A (x) - places a reference to 

address x into the Polish sequence. Type LOC 
is associated with the address. 

4) EMITAC(s,t) - places a reference to the 
constant string s of type t into the 
Polish sequence. 
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5) EKITI (t) - places a reference to an operand 

of type t with an indeterminate value into the 
Polish sequence. 



Additionally, the CSFE handles "branch point 
resolution." Branch points are referenced symbolically in 
the Polish sequence during compilation. A particular point 
in the sequence can be given a symbolic name for future 
reference. Whenever a symbolic location is defined, an ENT 
is inserted. Furthermore, references can be made to 
locations which have not as yet been compiled, called an 
"unresolved reference." When an unresolved reference 
occurs, the CSFE "resolves" the reference by inserting an 
address in the ADDR field of all XIT operands that 
previously referenced the symbol. 



The CSFE procedures for label processing are: 



1) EHITE(s) - ENT type variable which resolves 
the top-most stacked reference to s. 

2) EMITB(s) - backward reference to a label 
s which ha.s already occurred. 

3) EMITF (s) - forward branch point which has 
not occurred. 



4) EMITPE(s) - ENT type variable that does, 
not resolve any references to label s, 
called a "push down entry." 



5) 



EMITPF(s) - forward reference to label 
which "pushes" all previous references 
to label s. An EMITE(s) will resolve 
reference but not the references which 
"pushed down . " 



s 

this 

were 
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ff 



6) SAVELA3 - saves the current state of 

the label stack. Used to process inner loops 
such as embedded for-loops. 

7) RESTORELAB - restores the label stack to 
the configuration present upon the last call 
to SAVELAB. 

Additional utility procedures are also present as 

follows: 

1) EMITR(x) - places a REFER operator into 
the Polish sequence. The ADDR field is 
set to x. This is normally called at each 
card boundary in the source program with a 
line number of x; therefore, if an error 
condition is detected, the Polish sequence 
is scanned backwards to the last REFER. The 
ADDR field along with the OFFSET freld 

at the point of error are combined to pinpoint 
the error in the original source program. 

2) EMITP(x) - places a PASS operator with 

an ADDR field of x into the Polish sequence. 
The PASS operator is ignored by the CSF. 

Thus, the PASS operator can be used to pass 
information to subsequent modules. 

3) EMITT(x) - places a TOG operator with an 
ADDR -field of x into the Polish sequence. 

The x value is a bit word representation 

of toggle flags that can be set on the compile 
pass for later detection by CSr. Compilation 
toggles are enabled or disabled in the 
ALGOL-E implementation by: 
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a) $CODE - results in the Polish 
sequence being interlisted with 
the source program. 

b) STABLES - causes CSF to give a 
full trace by table dumps of the 
optimization process. 

c) $EXEC - causes a partial trace of 
the CSF analysis. 

d) $TRACE - causes CSF to give a 
partial trace of the optimization 
process . 

During the interlisting of the Polish sequence, 
(i.e. # SCODE is selected), each line of the code trace will 
hold 

1) OFFSET field - not used 

2) OPCODE/TYPE - operator or operand type 

3) C field - constant indicator 

4) ADDR field - address 

5) 32-bit word in hexadecimal format. 

A "+" before a line indicates the resolution of a 
forward reference while a "++" indicates that the entry 
point at that line number has caused the resolution of a 
forward reference or has been referenced again as a backward 
reference. The ADDR field of each ENT variable is 

incremented on each reference from an XIT variable. 
Therefore, it contains the number of branches into the 
location of ENT. TABLE IV is an example of the code 
interlisting option. 
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The ''constant table" is appended to the end of the 
Polish sequence. This table provides a character string 
representation of each constant encountered in the source 
program. The entire code file (i.e., Polish sequence and 
constant table) is passed to the CSF at the end of 
compilation. 



B. OPTIMIZING FUNCTIONS INCORPORATED IN THE CSF 

Before giving the details of the CSF implementation, it 
is necessary to describe the optimizing function and meet 
operator currently used. Information for three forms of 
optimization is collected: 

1) Constant Propagation 

2) Simplifying Formal Identities 

3) Common Subexpression Elimination. 

1 . Co ns tant P ropag ation 

The pool associated with each basic block is a 
partition of the program expressions. Constant propagation 
requires that a constant indicator be associated with every 
equivalent class. For. example: 

A : = 2 ; 

B := 3; 

C : = A + B ; 

could be rewritten as 

C := 5; 

since A and B are both known constants. Therefore, the pool 
associated with each node is a partition with a constant 
indicator for each equivalence class. The meet operator 
combines the constant indicators. 
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TABLE IV 



ALGOL-E CODE INTERLISTED PROGRAM 



CARO BLi^ 

l I o| 

►tEXECUTE 

►$CCDE 
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I n 7 58 | 000BD102 



COMPILER 
'CONTROL CARDS 

7 | 11 
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5 
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13 

CODE FILE COPIED (45 WORDS) 
CONSTANT TABLE COPIED (4 WORDS ) 
2 RECORDS WRITTEN INTO FILE 1 
END OF COMPILATION FEBRUARY 9, 

13 CARDS WERE READ* 

NO ERRORS WERE OE TEC TED • 
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ALGOL-E SOURCE 

BEGIN LOCAL A,B,C,D,E; 
C 2; 

D := 3; 

READ (A,B); 

WHILE A GTR B DO 
B C + D; 

E :** D + C ; 

END 
EOF 



< 



BRANCH POINT RESOLUTION 



1975. CLOCK TIME = 18:2:58.02. 
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. Simplifying; of Formal Identities 

A list of the simplifying formal identities 
specified in the CSFG are available in tabular form in the 
CSF . During the analysis, the expressions are compared with 
this table and transformations are made if a match is found. 
For example, the expression 

A : = A + 0 ; 

matches the form of the additive identity and could, 
therefore, be eliminated. Thus, no optimizing function or 
meet operator need be specified since these transformations 
are all local. 

3. Common Subexpression Eli mi nation 

As descri bed in S 0 c b ion T c « f b h 0 pools for cordon 
subexpression elimination consist of partitions of program 
expressions into groups that are known to have identical 
values. The meet operator is defined as the intersection on 
the equivalent classes. 

The combination of the above three optimization 
forms are incorporated into the current CSF. This 
combination logically allows detection of a fourth 
optimization form, common subexpressions that are linked to 
a previous constant propagation. The meet operator is the 
intersection operator. The four types are detected using a 
hierarchy of: 

1) Propagated Constants 

2) Simplifying Formal Identities 

3) Common Subexpressions that link to a 
Propagated Constant 

4) Common Subexpressions. 
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c. 



CODE SYNTHESIS FILTER (CSF) 



The following sections give the programming structures 
and methodology that are used in the implementation of the 
global flow analysis algorithm. The CSF module was written 
in the XPL language utilizing the XCOM control system [37]. 



1 • Prog ram Fl ow 



The actual implementation of the global flow 
analysis algorithm is incorporated in this module. In order 
to analyze the input Polish sequence, a "meta-execution 1 ’ is 
performed on the intermediate language. This process 
utilizes the "value number" concept of Cocke [10] which 
results in a more simplified data structure than would 
normally be expected. The "value number" will be referred 



to as a "class number," and an equivalence cla: 
one such class number assigned to it. 



wall hav 



The CSF is separated into three logical, parts: 

1) Initialization 

2) Control Flow Analyzer (CFA) 

3) 3asic Elock Analyzer (BBA) . 

The initialization routines accept the intermediate 
code file from the C3FE and prepare all data structures for 
processing. It is here that a CONSTANT TABLE is built as 
produced by the ALGOL-E compiler. 

The CFA controls the flow of processing from block 
to block, performs the meet operation and terminates the 
CSF. 
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The EBA is invoked to analyze each block (i.e., the 
application of the optimization function) . It is here that 
meta-execution takes place and optimization information is 
detected. Figure 5 depicts the overall flow of the CSF. 

The enclosed listing of CSF has been fully annotated 
in order to provide documentation of individual routines. A 
complete discussion of table structures and the more 
important procedures are given in the following sections. 

2. Method ol ogy 

The implementation of the global flow analysis 
algorithm was done using structured programming concepts. 
All functions are isolated within procedures and each 
procedure is as autonomous as possible. A complete 
description of the program organization and output can be 
accomplished by examining four areas: 

1) Control Structures 

2) Meta-Execution 

3) Meet Operation 

4) Output Formats. 

a. Control Structures 

The program branching structure is followed by a 
procedure called "CONTROL-FLOW/" the Control Flow Analyzer 
(CFA) . The CFA repeatively cycles through the following 
steps : 

1) select a blocx to be processed 
from the top of the list L. 

2) call the Basic Block Analyzer (DBA) 
to process the block. 
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STOP 



FIGURE_5 

OVERALL FLOW OF CSF 
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3) use the P produced by the 

o 

the BBA to perforin the meet operation 
on all successor blocks. 

4) order the blocks to be processed list 
according to the block selection rule 
in effect. 

These steps are continued until no blocks are available to 
be processed in step 1. The CFA then calls a procedure, 
"OUTPUT_OPTIMIZATION, " which writes an annotated 
intermediate language code file along with a synopsis of the 
optimization process. 

The "blocks to be processed list," L, consists 
of two elements as follows: 

1} CONTROL is a thirty-two (32) bit entry of: 

BITS CONTENT 

0-15 first word address of the block 

in the code file, 

16 set if initial pool has been 

built for this block, 

17-30 immediate predecessor block 

number, 

31 set if block is not to be 

processed (i.e., P < P in 

c i 

step Q5 of the flow algorithm).- 
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. 2) SAV-TOG is an eight (8) bit entry of: 

BIT 

0 set if control flow trace of 
optimization process desired, 

1 set if complete table trace of 
optimization process desired, 

2 set if detected constant operands 
are to be propagated, 

3 set if false branches are to be 
removed from detected constant 
decision branches, 

4 set if output from CSF is desired in 
punched cards, 

5-7 are not currently used. 



The function of the two tables is to save blocks 

to be processed along with optimizer toggles for each block. 

If it is found that a block need not be processed (i.e., the 

test of P < P is true after performing the meet operation 
c i 

in step Q5 of the algorithm) a single bit can be set rather 

than rearranging the table sequence. If an immediate 
successor block has never been encountered before, its P 

c 

becomes the P from the immediate predecessor block in the 

o 

procedure " BUILD_I NPUT_POOL . " 

Blocks are entered on the top of the "to be 
processed list," L as they are encountered by the BBA (i.e., 
when a branch operator is encountered) . After performing 
the meet operation on all successor blocks, the CFA calls 
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the procedure "ORDER_BLOCK_LIST, " which arranges the "to be 



processed list," L, in 


a 


top 


down 


sequence 


for actual 


processing according 


to 


the 


specified 


block 


selection 


method. Presently, any 


one 


of 


four 


(4) 


block 


selection 



methods can be specified. The are: 

1. Last-in-Firs t-out (LIFO). 

2. First- in-F irst-out (FIFO). 

3. Select the P with the minimum number 

i 

of equivalence classes called the 
min pool selection method, as 
discussed by Lukasczyk [34]. 

4. Select the P with the maximum number 

i 

of equivalence classes called the 
max pool selection method. This 
was included for comparison 
against the min pool selection 
method . 

In order to control block processing, a "block 
header" for each block is generated when it is first 
encountered. This header is updated each time the block is 
traversed; consequently, it provides a summary for the block 
at any point during the optimization process. These block 
headers are saved sequentially above the intermediate 
language code file. The block header format is: 

WORD CONTENT 

0 Block # (15 bits) | previously 
processed indicator (1 bit) | 
STATES TABLE index (16 bits) 

1 First word address in code 
file (16 bits) | last word 
address in code file (16 bits) 
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2 

3 

4 



Number of transversals 

Number of references 

Number of predecessor blocks 
referencing this block 
(variable number of 
entries) . 



Prior to passing a block's first word address to the BBA, 

the CFA places its P on the ADDRESS and EXPRESSION TABLES 

i 

using information from the STATES TABLE. These tables are 



among the primary mechanisms for the meta- execution 
performed by the BBA and will be discussed in the next 
section. In this manner, the meta-execution tables are 
preset for any block thus allowing random processing of 
blocks. 



The meet operation is performed by the CFA 

through a call to the procedure PERFORM_MEET_OP which 

applies the meet operator to a single immediate successor 

block of the block just processed. A true response from the 

PERFORM_MEET_OP procedure indicates that the immediate 

successor block is to be processed (i.e., the test of P < 

c 

P in step Q5 of Algorithm Q) . As was mentioned previously, 
i 

a single bit in the CONTROL TABLE entry for each successor 
block is then set or cleared to indicate future processing. 
The meet operation will be discussed in more detail in 
Section II.C.2.C. 



b. Meta-Execution 

The meta-execution is performed within the 
procedure BASIC_BLOCK which is the control routine for the 
BBA. The Polish sequence is symbolically evaluated using an 
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EXECUTION STACK. This process uses "class numbers" instead 
of the actual value of a variable since the actual value is 
not generally known at compile time. The EXECUTION STACK 
has four (4) elements: 

1) EXVAL# - a sixteen bit entry which holds 
the class number. 

2) EXTYPE - an eight bit entry which holds 
the type of an operand (e.g., BOOL or 
INT) . 

3) EXCON - a one bit indicator to 
identify an entry as a constant. 

h) EXADD - a sixteen bit entry that points 
to the ADDRESS TABLE entry that 
corresponds to this EXECUTION STACK entry. 

Three other table structures are used in 
conjunction with the EXECUTION STACK. They are the ADDRESS 
TAELE, the EXPRESSION TABLE and the CONSTANT TABLE. 

The ADDRESS TABLE defines all variables. There 
are five (5) entries per variable: 

1) ADDRESS - a thirty-two bit entry that holds 
an internal code that identifies each 
variable. This code is generated in 
sequence by the ALGOL-E compiler beginning 
with the first declared. This field 

will be zero if an ADDRESS 
TABLE entry defines an expression. 

2) ADDTYPE - an eight bit entry that defines 
the type of the variable. 
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3) ADDVAL - a sixteen bit entry that holds the 
current class number assigned to the 
variable. 

4) ADDCON - a sixteen bit entry that addresses 
the proper entry in the CONSTANT TABLE, 

if the current value of a variable is a 
constant . 

5) ADDNAH - a sixteen bit index to the 
EXPRESSION TABLE if the entry defines 

an expression. In this case, the ADDRESS 
entry would be equal to zero. 

The CONSTANT TABLE structure consists of four 
(4) elements that define each constant. The elements are: 

1) CONSYM - a character string representation 
of the constant, 

2) CONTYPE - an eight bit entry that defines 
the type for the constant. 

3) CONVAL a sixteen bit entry that holds 

the class number assigned to the constant. 

4) CONINT - a thirty-two bit binary 
representation of the actual constant 
value. 

The EXPRESSION TABLE {VTAB) is structured as a 
linear table with sequential expression entries made as they 
occur. A hash coded retrieval method is used to access the 
table resulting in rapid search for redundant expressions. 
The lower portion of VTAB up to HASHBASE is saved for the 
primary hash link. Access to this link is formed by 
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INDICATOR + OPERATOR + OPERAND class number + 

0 

OPERAND class number +...+ OPERAND class number. 

1 n 

The link address obtained will either hold a zero indicating 
no expression with this hashcode has been encountered, or an 
index to the most recent expression that hashed to this 
address. The INDICATOR in the hash formula is used to 
determine where the class numbers for the operands can be 
found. Specifically, the expression is located either in 
the EXECUTION STACK or in the EXPRESSION TABLE. An 
EXPRESSION TABLE entry is structured as: 



WORD 

0 



1 



2 



2+1 



2 + 1+1 



2 + I + J + 1 



CONTENT 

Bits 16-31 hold the original 
Hash Link address. Bits 0-15 
hold the operator code. 

Hash code collision field 
which is zero (0) if no further 
expression links are present. 

Class number for operand . 

0 

Class number for operand 

1 

(variable number of operands 
allowed) . 

Class number for resultant 

operand . 

0 

Class number for resultant 
operand^ (variable number of 

resultant operands allowed) . 



Master chain pointer links all 
entries. Used for bookkeeping. 
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Additionally, the upper portions of the ADDRESS 

TABLE and EXPRESSION TABLE are used to hold the P for a 

c 

block, as will be further explained in Section II.C.2.C. 



The meta-execution operates by loading Polish 
operands onto the EXECUTION STACK and setting indexes to 
their respective ADDRESS TABLE entries. When an operator is 
detected in the Polish sequence, the EXPRESSION TABLE is 
searched for an identical entry using the hashcode chain. 
In this manner, common subexpressions are easily detected. 

Because of the link from the ADDRESS TABLE to 
the CONSTANT TABLE, the detection of constant propagation is 
a simple matter of bit checking on the operands of an 
expression. If all operands are in fact constants, a 
propagated constant has been detected. 

The application of simplifying formal identities 
is done by a comparison against a table of simplification 
rules generated by CSFG for each expression. Both 
propagated constants and simplif icaxion detection are 
accomplished by a call to the procedure SIMPLIFY by the BBA. 
The generated constant propagation case statement shown in 
TABLE III, is located in the procedure PROPAGATE which is 
invoked when a propagated constant is detected by the 
procedure SIMPLIFY. PROPAGATE then computes the propagated 
constant as specified by the operator. The constant value 
is then entered into^ the CONSTANT TABLE if it does not 
already exist. 
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As possible code transformations are detected, 
they are also flagged in the table OPTIM_TY?E which has a 
parallel entry for each code word. The entries in the 
OPXIM TYPE TABLE are coded as: 



CODE 


MEANING 


0 


no transformation present 


1 


simplification possible 


2 


propagated constant 


3 


common subexpression 


4 


common subexpression that links 




to a propagated constant. 



Additionally, an optimization entry is saved for future 
reference at the extreme top of the EXPRESSION TABLE (VTA3) . 
The address of this optimization entry is entered into the 
ADDS field of the intermediate code for use by later passes. 
The form of this entry is: 



VTAB LOCATION 


CONTENTS 


VTOPR 


operand class number 
0 


• 


(variable number of 


• 

• 


operands) , 


VTOPR - X 


code location at which an 




identical expression can be 




found. Zero (0) if not 




applicable. 


VTOPR - X - 1 


resultant operand class 




number. 



where VTOPR is the current pointer to the last entry in the 
top of VTAB. Upon subsequent passes for a block, this 
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optimization expression entry will be updated as necessary. 
If a previous optimization does not recur on a subsequent 
pass, the indicator in OPTIM_TYPE is reset to zero (0), but 
the optimization expression entry remains linked. 



During the BBA, the tables generated by the CSFG 
come into use. The linkage between tables is in some cases 
rather complex and needs clarification for a complete 
understanding of the C5F. 

In order to identify the operator codes in the 
code file, two (2) tables are used: 

1) OPRANGF 

2) OPCODES. 

OPRANGE is a table that is indexed by the OPCODE 
field in the code file. Each entry addresses the first 
character for a particular OPCODE in the character string 
called OP_CODES. Figure 6 illustrates this relationship. 



To assist in the processing of expressions, five 
(5) tables are used: 



1) OP_DEGL 

2) 0P_DEGR 

3) 0P_1NDEX 

4) 0P_1NF0 

5) 0P_STR. 



0P_DEGL is indexed by OPCODE and 
number of operands necessary for an operator. 



contains the 



OP_DEGR is indexed by OPCODE and contains the 
number of result operands that the operator will generate. 
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OP RANGE 



OP CODES 



(OPCODE ) 
0 



(OPCODE ) 






FIBST 

CHARACTER 



LAST 

CHARACTER 

FIRST 

CHARACTER 

LAST 

CHARACTER 



FIRST 

CHARACTER 



FIGURE_6 

OP RANGE TO OP CODES RELATIONSHIP 
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OP_I NDEX is indexed by OPCODE and points to the 
first entry in OP_IMFO for an operand. OP_INFO holds the 
type code for each operand and resultant operand up to entry 
ninety-five (35) in the ALGOL-E implementation. As noted in 
Figure 7, more than one configuration of operand and 
resultant operand types can exist for a particular operator. 
The OP_DEGL and OP_DEGR counts provide a means of breaking a 
multiple configuration into its exclusive parts. 

For the ALGOL-E implementation, the OP_INFO 
TABLE above entry ninety-five (95) is used in conjunction 
with the SIMP_IND3X TABLE and the OP_STR TABLE to identify 
simplification rules. SIH?_INDBX is indexed by the operator 
code and indexes the first simplification rule in OP_INFO 
for that operator. Table OP_SIR holds the string 
representation of the identity operands "1" and "O' 1 for 
ALGOL-E. Each entry of OP_INFO is eight (3) bits as 
follows: 

BIT CONTENT 

0 1 = identity operand 

0 = variable identifier 

1-7 if identity operand this field 

points to OP_STR for 
proper identity. If variable 
operand this field holds 
the type code. 
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OP INDEX 



OP INFO 



ENTRY 0 



(OPCODE ) 
0 



(OPCODE^) 






ENTRY 95 





(TYPE 


CODE) 


(TYPE 


CODE) 


(TYPE 


CODE) 


(TYPE 


CODE) 


(TYPE 


CODE) 


(TYPE 


CODE) 









-OP 



-OP 



-OP 



OP 



FIGURE_7 

OP INDEX TO OP INFO RELATIONSHIP 



DEGL 



DE5R 



DEGL 



DEGR 
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Each entry of OP_INFO is a description of an 
operand or a resultant operand. Figure 8 depicts the 
Simplification Link Structure within OP_INFO. Note that 
more than one rule can exist for an operator in DP_INFO. A 
link from rule to rule is present, and OP_DEGR and 0 P_DEGL 
are used to process each rule. The last link field contains 
zero (0) which serves as the rule terminator for an 
operator. When a rule is matched against an existing 

expression, a siraplif ication has been found. 

The BBA sequentially processes the Polish 
elements beginning with the block's first word address 
provided by the CFA. Since the BBA processes only basic 
blocks, it returns control to the CFA upon encountering a 
branch operator or an ENT type variable. Any XII' operands 
encountered by the BBA result in entries on the CONTROL 
STACK with the ADDR field specifying the first word address 
of the immediate successor block. An ENT variable also 
results in a CONTROL STACK entry beginning at the next 
sequential instruction in the code file. 

Because of constant propagation, the BBA is able 
to alter the actual block flow of the program if a 
propagated constant is detected while processing a 

conditional branch operator. For example, given the program 

A : = 5 ; 

B : = 10; 

IF A > 3 THEN 

C : = 6 ; 

D := 7; 
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SIMP INDEX 



OP INFO 




SIMPLIFICATION LINK STRUCTURE 



ENTRY 95 



OP DEGL 



OP DEGR 



OP DEGL 



OP DEGR 
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the test of A > B would obviously always be false. When 
this condition is detected, only one of the XIT variables 
generated by the compiler would be placed on the CONTROL 
STACK. This can result in entire sections of a program 
never being traversed. The flow of the above example would 
effectively become 

A : = 5 ; 

B := 10; 

D ;= 7; 

This facility can be controlled by a toggle called 
BRA HCHTOG . If it is false, both exits will always be 
processed. Currently it is set to a true condition. 



c. Meet Operation 



The meet operation is accomplished from within 

procedure PERFORM_MEET_OP which is called by the CFA. Each 

call results in a single immediate successor block being 

processed. A true or false response indicates to the CFA 

whether the immediate successor block is to be marked for 

future processing. That is, if P < P , then 

c i 



PERFORM MEET OP returns false. 



The P for a block is saved via the STATES TABLE 
c 

in the upper portions of the ADDRESS and EXPRESSION TABLES. 
The STATES TABLE is a linear table which is structured as: 
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WORD CONTENT 

0 0 

always zero 

1 0 

2 number of states for block #1 

. (index to ADDRESS table 

. for each state) 



2 + 1+1 
2+1 + 2 
2 + 1 + 3 



0 

0 

number of states for block #2 



etc 



etc 



where a ''state' 1 is a single variable or expression 

description. The block header for each block points to its 

respective STATES TABLE entry. The ADDRESS TABLE entry for 

the P is nearly identical to the format previously 

c 

discussed; however, it is saved linearly from the top down 

instead of from the bottom up. The EXPRESSION TABLE entry 
is also slightly different. An ADDRESS TABLE entry 
corresponding to an expression entry will still have zero 
(0) in the ADDRESS entry. However, the ADDNAM pointer will 
address the top cf VTAB instead of the bottom. In VTAB, 
only the operands for the expression will be found. Note, 
finally, that the complete state of any one block is 
distinct from the other blocks; that is, no ADDRESS TABLE 
state entry is shared by blocks. 

An important point in understanding the 
structure of the EXPRESSION TABLE (VTAB) is that it holds 
three separate entries. They are: 
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1 ) 



current expressions for the block being 
processed, 

2) information on detected transformations, 
and 

3) operands for the saved current optimized 
pools of all blocks. 

Only the current expression ■ entries are hash coded, and 
reside in the lover part of VTA3. The other two entry types 
are found in the upper regions of VTAB. 

Prior to calling PERFOR M_ME ET_OP , the C?A 

structures the lower ADDRESS TABLE so that it completely 

reflects the P of the last processed block. This is 

o 

accomplished by moving any EXECUTION STACK entries onto the 



ADDRESS TABLE. The ADDRESS field will be a number 

representing the relative position of the entry on the 

EXECUTION STACK. The uppermost bit (bit 15) of the ADDRESS 

field is set to identify the entry as originating from the 

EXECUTION STACK. Therefore, the meet operation need only 

look at the lower ADDRESS TABLE for the P and the upper 

o 

ADDRESS TABLE specified by the STATES TABLE for the P of 

c 



the immediate successor block. 



The meet operation is accomplished in three (3) 

steps: 

1) Initialize 

2) Process all simple variables 

3) Process all expressions. 

Two (2) tables, the CLASS OCCURRENCE LIST and the CLASS 
REFINEMENT TABLE, are the primary structures used to 
accomplish the meet operation as developed by Kildall [28]. 
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The initialization stage builds the CLASS OCCURRENCE LIST 

based on the P of the block to be processed. This list is 

c 

simply a count of the occurrence of each class number that 
is assigned to a simple variable or an expression. 

After the CLASS OCCURRENCE LIST is built, all 

simple variables are processed from the P of the immediate 

c 

successor block. The P is searched for each identifier in 

o 

the P . If the identifier exists, the class numbers from 
c 

the two (2) pools are entered into the CLASS REFINEMENT 

LIST. If the class numbers are not the same, a new "refined 

class number" is assigned to the identifier. The identifier 

is then placed in the P with the refined class number. As 

i 

each identifier is processed from the P , its class 

c 

occurrence is decremented in the CLASS OCCURRENCE LIST. 

After all simple variables have been processed, 

each exptession in the P is considered. When an 

c 

unprocessed expression is found, a check is made to ensure 

that the the CLASS OCCURRENCE LIST for all its operand class 
numbers are zero (0) . If they are not, the expression is 
not processed until they are, with a single exception. 
Simplif ication rules such as 

A + 0 = A 

cause both (A + 0) and A to appear in the same class. When 
this occurs, (A + 0) is treated the same as A. 

If an expression can be processed, its resultant 
class number count is decremented in the CLASS OCCURRENCE 
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LIST 



. A list of candidate expressions to consider in the ? 

o 

is forme’d by examining the CLASS REFINEMENT LIST. If an 

expression in the P has operands OP and OP , a search of 

c 12 

the CLASS REFINEMENT LIST will be made to identify class 

numbers in the P that are equivalent to OP and OP . For 

o 12 

example, if an output pool is 



P = {A j B | A + B, B + A} 
o 

(D (2) (3) 



and a current pool is 

P = {A | B | A + B, B + A} 
c 

(5) (6) (4) 

where each class is labeled with a class number. The CLASS 
OCCURRENCE LIST would be: 

NUMBER OF OCCURRENCES CLASS' NUMBER 

1 4 

1 5 

1 6 



After processing simple variables, the CLASS OCCURRENCE LIST 
would be; 

NUMBER OF OCCURRENCES CLASS NUMBER 

1 4 

and the CLASS REFINEMENT TABLE would be 

P CLASS NUMBER P CLASS NUMBER REFINED CLASS NUMBER 

o "c 



1 5 7 

2 6 8 



69 



I 



Since identifiers 
point would be 



A and B were both found, the P to this 

i 



P. = [ A | B }. 

l 

(7) (8) 

Upon searching the CLASS OCCURRENCE LIST for the operand 

class numbers of the expression (A + B) in the P , none will 

c 

be found; therefore, the expression can be processed. The 

resultant class number, 4, is deleted from the CLASS 

OCCURRENCE LIST. Using the CLASS REFINEMENT TABLE a list of 

candidate expressions to search for in the P is 

o 

constructed. This list is developed by taking the operands 

of the expression in the P and searching the CLASS 

c 

REFINEMENT TABLE for matches • in the P . For example, a 

o 

class number of 1 in the P is equivalent to a class number 

o 

of 5 in the P and a class number of 2 in the P is 

c o 

equivalent to a class number of 6 in the P . Therefore, the 

c 

expressions to be searched for would be 

P EXPRESSION LIST 
o 

(5) + (6) 

(6) + (5) 

since the operator "+" is commutative. The P is then 

o 

searched for an occurrence of these expressions. If found, 

the resulting class numbers of the P and P expressions aLe 

c o 

entered in the CLASS REFINEMENT TABLE in the same manner as 
for an identifier. 
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P CLASS NUNBEE 
”o ~ 

1 

2 

3 



P CLASS NUMBER 
c ~ 

5 

6 
4 



REFINED CLASS NUMBER 

7 

8 
9 



An expression entry can then be made in the P 

i 

using the refined class numbers for both operands and 

resultant operands. The P would then be 

i 

P = { A j B | A + B, B+A}. 

i 

(7) (8) (9) 

After all expressions have been processed, the CLASS 



OCCURRENCE 


LIST 


wi 


11 be empty. If 


an 


expression or 


identifier 


in 


the 


P is not found in 

c 


the 


P , the current 
o 


state of P 


has been 


altered and PERFORM 


MEET 


CP will return 



c 



true, indicating the block must be traversed again. 

A problem with the handling of constants occurs 

if an identifier or expression is a constant in the P and 

c 

is present in the P but its value is not a constant in the 

o 

P . The state has chanqed in this situation, thus reguirina 
o 

a true response from PERFOR M_MEET_OP . 

As each identifier and expression is processed, 

the P area at the top cf the ADDRESS TAELE is updated, 
c 

This is the P that is being formed, which is to be loaded 

i 

onto the lower ADDRESS TABLE by the CFA before calling the 
BBA to process the block. At the completion of the CSF, the 
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P held within the upper ADDRESS TABLE is the P (i.e., MOP) 
c F 

for each block. 

d. Output Formats 

A number of table formats have already been 
discussed; however, further output format definitions for 
the equivalence classes and the final optimization 
information is necessary. 



The state elements have one of -three formats: 

1) A (X, Y, Z) 

2) E (X, Y, Z) 

3) C (X, Y, Z) . 

Form A (X, Y, Z) refers to a simple identifier and 
X is the identifier code number, 

Y is the class number of the constant 

if identifier X is equal to a constant, 
and 

Z is the class number assigned the identifier 
X in the ADDRESS TABLE. 

Form E (X, Y, Z) refers to an EXECUTION STACK entry and 

X is the relative location of the entry from 
the top of the EXECUTION STACK. Y and 
Z are the same as for a simple identifier. 

Form C(X, Y, Z) refers to an expression entry and 

X represents the class numbers of all operands 
separated by colons, 

Y is the class number of the constant 
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if the resultant class number is 
equal- to a constant, and 

Z is the class number of the resultant operand. 

Another format for expressions is used when the 
expression stack is output at the end of processing each 
block. Its form is: 

C (X, Y , Z) 



where 

X is the string representation of the 
expression operator, 

Y is the same as for X in state expressions, and 
Z is the same as for Z in state expressions. 



form 



where 



The final optimization results are output in the 

Optimization at X 
(a ^ r a^, I £> / c) 



X is the location in the intermediate 
code file where the optimization 
was detected. 



a , a , ..., a are the class 
12 k 

numbers of all operands, 

b is the address of a previous expression 
that is identical, if one exists, and 

c is the resultant class number of the expression. 

In all of the above formats, an unknown element will be 
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printed as 



If * H 

r m 



The block 

optimization process. 



headers are output at the end of the 
The format for each block is: 



LINE 

1 

2 



3 



CONTENT 
block number 

first and last word addresses 
within the intermediate code 
file for the block 

count for the number of 
times the block was traversed 



4 block number of an immediate 

predecessor block 

4+1 (variable number of predecessor 

blocks possible) . 



The intermediate code file is also printed,, ana the C field 
indicates the actual location of any optimization 
information. The OPTIM_TYPE TABLE is output concurrent with 
the code file to indicate the optimization type. 



Several examples of CSF output are enclosed in 
which different block selection methods were used as 
indicated on the output. TEST program number six (6) has 
all four block selection methods listed so that a comparison 
of the CSF flow using different block selection methods can 
be seen. 



TABLE V is the CSF output from the source 
program shown in TABLE IV with STABLE selected. The 
different tables are identified as they occur. 
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TABLE V 

• TABLE TRACE OUTPUT FROM CSF 

♦♦♦CODE SYNTHESIS FILTER*** 

BLOCK SELECTION METHOD WILL BE STEEPEST DESCENT (MINIMUM CURRENT POOL) 

***C OMPLETE TABLE DUM P*** 

DUMP REQUESTED FROM BLOCK NUMBER = 0 AT LOCATION = 0 



**#T A B 1 

CONSTANTS 

CONSYM 

CONTYPE 


. E 

<l> 

2 

INT 


D U 

<2> 

3 

INT 


M P*** AT 
<3> <4> 


LOCAT 

<5> 

— * 


ION = 
<6> 


0 

<7> 


<8> 


<9> 


<10> <ll> <1 2> < 13> 
CONSTANT TABLE 


<14> 

FROM CSFE 


CONVAL 


46 


47 




















CONINT 


2 


3 




















ADDR TABL 


<1> 


<2> 


<3> 


<4> 


<5> 


<6> 


<7> 


<8> 


<9> 


<10> <11> < 1 2> <1 3> 


<14> 


(EMPTY) 


















- SIMPLE VARIABLES STACK IS EMPTY 


VALUE STACK (TOP AT 


127) 












- EXPRESSION STACK IS EMPTY 




CONT ST K 


<1> 


<2> 


<3> 


<4> 


<5> 


<6> 


<7> 


<8> 


<9> 


<10> <11> < 1 2> < 1 3> 


<1V> 


BLOCK# 1 

ENTRY I 


1° 

to 
















SET TO PROCESS BLOCK 111 






















STARTING AT LOCATION 0 




EXEC STAC 


<1> 


<2> 


<3> 


<4> 


<5> 


<6> 


<7> 


<8> 


<9> 


<10> <11> < 1 2> <1 3> 


<u> 


(EMPTY) 


-M — 
















■cv 


TOITT T DM CT4TV TC FVfDT’V 





ERMED1 ATE CODE DUMP **** 

C NS ADR RAW CODE OPTIMIZATION 

/ETC TYPE 

******** ****************************************** 



INITIAL ENT IS FORCED BY THE 
INITIALIZATION ROUTINES 



**** FORMATTED INT 
LOC OFF OP CODE 
SET 

i *** ** ** * * ** * ** * * *** * 

0 

2 

3 

4 

5 

6 

7 

8 

9 

10 
11 
12 

13 

14 

15 

16 

17 

18 

19 

20 
21 
22 

23 

24 

25 

26 

27 

28 
' 29 

30 

31 

32 

33 

34 

35 

36 

37 

38 

39 

40 

41 

42 

43 

44 

45 

t*************4$**£*£*'*********4*t*4*£*4c < '4 ( £ <( £4$ 2 e', l !'4* 4 '******* *********** 



0 


ENT 


C 


46 


0003802E 


0 


TOGGLE 




1257 


00 OB 0 1 0 1 


0 


TOGGLE 




2 58 


00030 102 


0 


ICC 




3 


00020003 


0 


INT 




1 


00050001 


0 


STO 




0 


00280000 


0 


DEL 




0 


00240000 


0 


LOC 




4 


00020004 


0 


INT 




2 


00050002 


0 


STO 




0 


00280000 


0 


DEL 




0 


002AOOOO 


0 


LOC 




l 


00020001 


0 


INT 




0 


00050000 


c 


STD 




0 


00290000 


0 


LOC 




2 


00020002 


0 


INT 




0 


00050000 


0 


STD 




0 


00290000 


0 


ENT 




1 


00030001 


0 


LOC 




1 


00020001 


0 


LOD 




0 


00270000 


0 


LOC 




2 


00020002 


0 


LOD 




0 


00270000 


0 


GTR 




0 


00210000 


0 


X I T 




37 


00040025 


0 


XI T 




26 


0004001 A 


0 


BSC 




0 


002F0D00 


0 


ENT 




1 


00030001 


0 


LOC 




2 


00020002 


0 


LOC 




3 


00020003 


0 


LOD 




0 


00270000 


0 


LOC 




4 


00020004 


0 


LOD 




0 


00270000 


0 


ADD 




0 


00100000 


0 


STO 




0 


00280000 


0 


DEL 




0 


002A0300 


0 


XI T 




17 


0004001 1 


0 


BRS 




0 


00 2F 0000 


0 


ENT 




1 


00030001 


0 


LOC 




5 


00020005 


0 


LOC 




4 


00020004 


0 


LOD 




0 


00270000 


0 


LOC 




3 


00020003 


0 


LOD 




0 


00270000 


0 


ADD 




0 


00100000 


0 


STO 




0 


00280000 


0 


DEL 




0 


002 AO 0 00 
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TABLE V (CON'T) 



BASIC BLOCK #1 

BEGINNING AT 0, ENDING AT 0 
BLOCK TRAVERSED 0 TIMES 
0 REFERENCES: 



•BLOCK HEADER 



♦♦♦E ND OF COMPLETE TABLE DUM P*** 

04-2 0 ITOGGLE I 1 2 58 | 00030102 TRACE IN BBA AT LOCATION 2 



***T ABLE DUM P*** AT LOCATION = 2 
INPUT POOL FOR BLOCK# 1 IS: 



(NULL) -4 

AODR TABL <1> 
(EMPTY) 


<2> 


<3> 


<4> 


<5> 


<6> 


<7> 


<8> 


<9> 


BLOCK 

<10> <11> 


n HAS 
< 1 2> 


A NULL 
<1 3> 


, INPUT 
< 14> 


VALUE STACK (TOP AT 


127) 










• 












CONT STK 
(EMPTY) 


<1> 


<2> 


<3> 


<4> 


<5> 


<6> 


<7 > 


<8> 


<9> 


<10> <ll> 


< 1 2> 


< 1 3> 


< 14 > 


EXEC STAC 
(EMPTY) 


<1> 


<2> 


<3> 


<4> 


<5> 


<6> 


<7> 


2 

<8> 


<9> 


<10> <11> 


< 1 2> 


<13> 


< 14 > 


B+3 0 


1 LOC 


1 


13 


1 


00020003 


1 












*** T A B l 
ADDR TABL 
ADDRESS 
ADDTYPE 

A DHW A 1 


_ E 
<1> 


D U 
<2> 


M P*** 
<3> 


AT 

<4> 


LOCATION = 
<5> <6> 


3 

<7> 


<8> 


<9> 


<10> <11> 


< 1 2> 


< 1 3> 


< 1 4 > 


NULL 

n 














LOC OPERATOR 


HAS RESULTED IN A 


SIMPLE 


AUUV AL 
ADDCON 


U 

0 














VARIABLE ENTRY BEING 'MADE IN ADDRESS 


TABLE 


EXEC STAC 


<i> 


<2> 


<3> 


<4> 


<5> 


<6> 


<7> 


<3> 


<9> 


<10> <ll> 


< 1 2> 


< 1 3> 


< 14 > 



EXCON 
EXTYPE 
EXADD (3 

EXVAL# |0 



N 
LOC 



EXECUTION STACK HOLDS ONE ENTRY OF TYPE LOC 
WHICH IS REFERENCING SIMPLE VARIABLE 3 (C) 



B+4 



INT 



***T ABLE 
EXEC STAC <l> 



EXCON 

EXTYPE 

EXADD 

EXVAL# 



B+5 



N 
LOC 
3 
0 



; STO 



***T ABLE 
ADDR TABL <1> 



ADDRESS 

ADDTYPE 

ADDVAL 

ADDCON 



3 

INT 

46 

1- 





i 


IX 


| 00050001 


0 U 


M P*** 


AT 


LOCATION = 


4 


<2> 


<3> 


<4> 


<5> <6> 


<7> 


Y 










INT 










1 

46 


















i 


1 


10 


I 00263000 


D U 


M P*** 


AT 


LOCATION = 


5 


<2> 


<3> 


<4> 


<5> <6> 


<7 > 



<8> <9> <10> <11> < 1 2> < 1 3> < 14> 

THE CONSTANT OF 2 IS NOW ON THE TOP OF THE 
“EXECUTION STACK. NOTE THE CONSTANT INDICATOR 
AND THE CLASS NUMBER. 

I 



<8> <9> <10> <11> < 1 2> <1 3> < 14 > 

THE VARIABLE 3 IS NOW SET TO POINT AT THE 
CONSTANT 2. 



EXFC STAC <1> <2> 



EXCON 

EXTYPE 

EXADD 

EXVAL# 



Y 
INT 
1 

46 



-POINTS TO CONSTANT TABLE 

<3> <4> <5> <6> <7> <8> <9> <10> <ll> <I2> <13> <14> 



B*6 



lOEL 



I 0Q2A0000 | 



ABLE DUM P*** AT LOCATION = 6 
XFCSTAC <1> <2> <3> <4> <5> <6> <7> 

* tn PT Y ) 



<8> <9> <10> <11> <12> <1 3> <U> 
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TABLE V (CON'T) 



B*7 0 


ILOC 


i 


14 


I 00020004 


1 














♦ **T A R 

ADDR TABL 

ADDRESS 

ADDTYPE 

ADDVAL 

ADDCON 


L E 
<1> 

13 

| I NT 
46 

1 


D U M P*** 
<2> <3> 

4 

NULL 

0 

0 


AT 

<4> 


LOCATION = 7 
<5> <6> <7> 


<8> 


<9> 


<10> 


<11> 


< 1 2> 


<1 3> 


< I4> 


EXEC STAC 
EXCON 
EXTYPE 
EXADD 
EXVAL # 


<1> 

N 

LOC 

4 

0 


<2> 


<3> 


<4> 


<5> <6> <7> 


<8> 


<9> 


<10> 


<11> 


< 1 2> 


<13> 


<14> 


B+8 0 


1 INT 


1 


12 


I 00050002 


1 














*#*T A B 

EXEC STAC 

EXCON 

EXTYPE 

EXADD 

EXVAL# 


. E 
<1> 
N 

LOC 

4 

0 


0 U M P*** 
<2> <3> 

Y 

INT 

2 

47 


AT 

<4> 


LOCATION = 8 
<5> <6> <7> 


<8> 

) 


<9> 


<10> 


<11> 


<12> 


<1 3> 


< 14 > 


B+9 0 


1 STO 


1 


10 


1 00280000 


1 














***T A B 

ADDR TABL 

ADDRESS 

ADDTYPE 

ADDVAL 

ADDCON 


. E 
<1> 

3 

INT 

46 

1 


D U M P *** 
<2> <3> 

4 

INT 

47 

2 


AT 

<4> 


LOCATION = 9 
<5> <6> <7> 


<8> 


<9> 


<I0> 


<11> 


< 1 2> 


<1 3> 


< 14> 


EXEC STAC 

EXCON 

EXTYPE 

EXADD 

EXVAL# 


<1> 

Y 

INT 

2 

47 


<2> 


<3> 


<4> 


<5> <6> <7> 


<8> 


<9> 


<10> 


<ll> 


< 1 2> 


<1 3> 


< 1 4 > 


BUO 0 


|DEL 


1 


10 


I O02AOO0O 


1 








' 






***T ABLE 
EXEC STAC <1> 
( EMPTY) 


D U M P*** 
<2> <3> 


AT 

<4> 


LOCATION = 10 
<5> <6> <7> 


<8> 


<9> 


<10> 


<11> 


< 1 2> 


<13> 


<1 4 > 


B*1 1 0 


1 LOC 


1 


11. 


I 00020001 


1 














***T A B l 
AOOR TABL 
ADOBE SS 
ADDTYPE 
ADDVAL 
ADDCON 


. E 
<1> 

3 

INT 

46 

1 


D U t 
<2> 

4 

1 NT 
47 

2 


1 P*** 
<3> 

1 

NULL 

0 

[0 


AT 

<4> 


LOCATION = 11 
<5> <6> <7> 


<8> 


<9> 


<10> 


<1 1 > 


<1 2> 


< 1 3> 


<14> 


EXEC STAC 

EXCON 

EXTYPE 

EXADO 

EXVAL# 


<l> 

N 

LOC 

1 

0 


<2> 


<3> 


<4> 


<5> <6> <7> 


<8> 


<9> 


<10> 


<11> 


< 1 2> 


<1 3> 


<14> 


B*12 0 


1 INT 


1 


10 


I 00050000 


1 














***T A B l 
EXEC STAC 
EXCON 
EXTYPE 
EXADD | 

EXVAL# 


. E 
<1> 
N 

LOC 

1 

0 


D U M P*** 
<2> <3> 

N 

INT 

0 

48 


AT 

<4> 


LOCATION = 12 
<5> <6> <7> 


<8> 


<9> 


<10> 


<11> 


< 1 2> 


<13> 


<14> 


B*13 0 


1 STD 


i 


10 


I 00290000 


1 
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TABLE V (CON'T) 



***T A B 1 


L E 


0 U M P*** AT 


LOCATION = 


13 


ADOR TAeL 


<1> 


<2> 


<3> 


<4> 


<5> 


<6> 


<7> 


ADDRESS 


3 


4 


1 










AODTYPE 


INT 


INT 


I NT 










ADOVAL 


4o 


47 


4 8 










ADOCON 


1 


2 


0 










EXEC STAC 


<1> 


<2> 


<3> 


<4> 


<5> 


<6> 


<7> 


(EMPTY) 
















B+14 0 


1 LOC 


1 


12 


1 


00020002 


***T ABLE 


0 U M P*** AT 


LOCATION = 


14 


ADDR TABL 


<1> 


<2> 


<3> 


<4> 


<5> 


<6> 


<7> 


ADDRESS 


3 


4 


1 


2 








ADDTYPE 


INT 


I NT 


INT 


NULL 






ADDVAL 


46 


47 


48 


0 








ADDCON 


1 


2 


0 


0 








EXEC STAC 


<1> 


<2> 


<3> 


<4> 


<5> 


<6> 


<7> 


EXCON 


N 














EXTYPE 


LOC 














EXADD 


? 














EXVAl# 


0 














B+15 0 


1 INT 


1 


10 


1 


00050300 


***T ABLE 


D U M P *** AT 


LOCATION = 


15 


EXEC STAC 


<1> 


<2> 


<3> 


<4> 


<5> 


<6> 


<7> 


EXCON 


N 


N 












EXTYPE 


LOC 


INT 












EXADO 


2 


0 












EXVAL # • 


0 


49 












B + 16 0 


1 STD 


1 


10 


1 


00293300 


♦ **T ABLE 


D U M P*** AT 


LOC AT ION = 


16 


ADDR TABL 


<1> 


<2> 


<3> 


<4> 


<5> 


<6> 


<7> 


ADDRESS 


3 


4 


1 


2 








ADDTYPE 


INT 


INT 


I NT 


INT 








ADDVAL 


46 


47 


48 


49 








ADDCCN 


1 


2 


0 


0 








EXEC STAC 


<1> 


<2> 


<3> 


<4> 


<5> 


<6> 


<7> 


(EMPTY) 
















8+17 0 


1 ENT 


1 


11 


1 


00033001 



INITIAL CURRENT OPTIMIZED POOL TO BE USED FOR 
A(2,*,49) A(l, *,48) A(4,47,47) A(3, 46,46) 



<8> <9> <10> <11> <1 2> <13> <14> 



<8> <9> <10> <11> < 1 2> < 1 3> <14> 



<8> <9> < LO> <11> <12> < 1 3> <14> 



<8> <9> <10> <11> <12> <1 3> <14> 



<8> <9> <10> <11> < 1 2> <1 3> < 1 4> 



<8> <9> <10> <11> < 1 2> <1 3> < 14> 



<8> <9> <10> <11> < 1 2> <13> < 14> 



ri nrk« ? re. THE INITIAL CURRENT 

a ! POOL FOR BLOCK It 2 IS THE 

OUTPUT POOL FROM BLOCK It 1 



***T ABLE D U M P*** AT LOCATION = 17 

CONT STK <1> <2> <3> <4> <5> <6> <7> <e> <9> <I0> <11> <12> <13> <14> 

ENTRY* 117 ** t BLOCKS TO BE PROCESSED LIST HAS A SINGLE 

ENTRY FROM BLOCK It 1 TO LOCATION 17. 

EXEC STAC <1> <2> <3> <4> <5> <6> <7> <8> <9> <10> <11> <12> <13> <14> 

(EMPTY) 



, CONTROL AT 17, FROM BLK 1 TO BLK 2 (PASS 1) 
C + 17 0 | ENT | C 1 50 I 00038032 



CFA PASSES CONTROL FROM BLOCK tfl TO 
BLOCK It 2. 



***T ABLE D U M P*** AT LOCATION = 17 
INPUT POOL FOR BLOCKS 2 IS: 

A( 2 , *, 49 ) A ( 1 , * , 48 ) A(4,47,47) A(3,46,46) 



ADORE SS 
ADDTYPE 
ADOVAL 
ADOCON 



<1> 


<2> 


<3> 


3 


4 


1 


INT 


INT 


INT 


46 


47 


48 


1 


2 


0 



<4> 

2 

I NT 
49 
0 



<5> <6> <7> <8> 



INPUT POOL 
" VARIABLES, 
<9> <10> 



FOR BLOCK #2.. STATE IS FOUR SIMPLE 
TWO OF WHICH ARE CONSTANTS. 

< 11 > < 1 2 > < 1 3 > < 14 > 
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TABLE 


V (CON'T) 


VALUE STACK (TOP AT 


127) ^ 






EXPRESSION 


CONT STK 


<i> 


<2> 


<3> <4> 


<5> <6> 


<7> 


<8> <9> 


(EMPTY) 














EXEC STAC 


<i> 


<2> 


<3> <4> 


<5> <6> 


<7> 


<8> <9> 


(EMPTY) 














8*18 0 


ILOC 


i ii 


1 00020001 


1 


***T A B L 


E 


D U 


M P*** AT 


LOCATION = 


18 




EXEC STAC 


<1> 


<2> 


<3> <4> 


<5> <6> 


<7> 


<8> <9> 


EXCON 


N 












EXTYPE 


LOC 












EXADD 


1 












EXVAL# 


0 










♦ 


B + 19 0 


1 LOO 


1 10 


1 00270000 


1 


***T ABLE 


D U 


M P*** AT 


LOCATION = 


19 ; 




EXEC STAC 


<1> 


<2> 


<3> <4> 


<5> <6> 


<7> 


<8> <9> 


EXCON 


N 












EXTYPE 


INT 












EXADD 


0 












EXVAL# 


48 












B*2 0 0 


ILOC 


1 12 


I 00020002 


1 


***T A B l 


. E 


D U 


M P*** AT 


LOCATION = 


20 




EXEC STAC 


<1> 


<2> 


<3> <4> 


<5> <6> 


<7> 


<8> <9> 


EXCON ] 


IN 


N 










EXTYPE 


INT 


LOC 










EXADD 


0 


? 










EXVAL# 1 


48 


0 










EH21 0 


1 LOO 


1 10 


1 00270000 


I 


***T A B L 


. E 


D U 


M P*** AT 


LOCATION = 


21 




EXEC STAC 


<1> 


<2> 


<3> <4> 


<5> <6> 


<7> 


<8> <9> 


EXCON ! 


IN 


N 










EXTYPE 1 


INT 


INT 










EXADD 


0 


0 










EXVAL# 1 


148 


49 











B*22 



IGTR 



I 10 



**<=T ABLE 0 U M P*** AT 
VALUE STACK (TOP AT 133) 

C (GTR 48 49 | 50 ) 



I 002 1 0300 __ I 
LOCATION = 22 




AN EXPRESSION ENTRY IS MADE. . WHILE A GTR B CO 
OPERANDS OF 48 AND 49 AND A RESULT OF 50. 



EXEC STAC <1> 
EXCON IN 

EXTYPE (BOOL 

EXAOO 10 

EXVAL# 50 



<2> <3> <4> <5> <6> <7> <8> <9> <10> <11> <12> <13> <14> 



8*23 



I XI T 



I 137 



I 00040025 | 



***T ABLE 
CONT STK <1> 
BLOCK# 12 
ENTRY 37 



0 U M P*** AT 
<2> <3> <4> 



LOCATION = 23 

<5> <6> <7> <8> <9> <10> <11> < 1 2> <13> <14> 



EXEC STAC 
EXCON 
EXTYPE 
EXADD 
EXVAL# 



<1> <2> <3> <4> <5> <6> <7> <8> <9> <10> < 1 1 > <12> <13> <14> 

N 

BOOL 

0 

50 
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6*24 



I XI T 



• TABLE V (CON’T) 

I |26 | 0004001A | 



♦♦♦T ABLE 0 U M P*** AT LOCATION = 24 

CONT STK <1> <2> <3> <4> < 5> < 6 > <7> < 8 > <9> <10> <11> < I 2> <13> <14> 
ENTRY** I 37 r I Ia -4 — =■ BLOCK #2 HAS GENERATED TWO IMMEDIATE SUCCESSOR BLOCKS. 



EXEC STAC <1> <2> <3> <4> <5> <6> <7> <8> <9> <10> <Il> <12> <13> <14> 



EXCON 

EXTYPE 

EXADD 

EXVAL# 



N 

BOOL 

0 

50 



B *2 5 



I BSC 



I 10 



I 002F3000 I 



INITIAL CURRENT OPTIMIZED POOL TO BE USED FOR BLOCK# 3 IS: 
C( 48 :49, *, 50) A(2,*,49> All, *,48) A( 4,47,47) A(3,46,46). 



INITIAL CURRENT OPTIMIZED POOL TO BE USED FOR BLOCK# 
C(48:49, *,50) A(2,*,49) All, *,48) A(4,47,47) A" 



CK# 4 IS: 
(3,46,46 ) “ 



CURRENT POOL FOR BOTH BLOCK 
If3 AND #4 HAS BEEN SET TO THE 
OUTPUT POOL FROM BLOCK #2. 



***T ABLE D U M P*** AT LOCATION = 25 

ADDR TABL <1> <2> <3> <4> <5> <6> <7> <8> <9> <10> <11> < 1 2> <13> <14> 

‘ ' “0 

GTR 
50 
0 



ADDRESS 


3 


4 


1 


2 


ADOTYPE 


IMT 


I NT 


I NT 


INT 


ADDVAL 


46 


47 


48 


49 


ADDCON 


1 


2 


0 


0 



EXEC STAC <1> <2> <3> <4> <5> <6> <7> <8> <9> <10> <11> <12> <13> <14> 

(EMPTY) 



CONTROL AT 26, FROM BLK 2 TO BLK 4 (PASS 1) „ 

C*26 0 I ENT I C 1 60 I 0003803C I 



CFA PASSES CONTROL FROM BLOCK II 2 TO 
BLOCK H. 



***T ABLE 



D U M P*** AT LOCATION = 26 



<1> 


<2> 


<3> 


<4> 


3 


4 


1 


l ? 


INT 


INT 


INT 


INT 


46 


47 


48 


49 


1 


2 


0 


1 o 



INPUT POOL FOR BLOCK #4 IS 
-FOUR SIMPLE VARIABLES AND 
ONE EXPRESSION. 

<8> <9> <10> <11> < 1 2> < 1 3 > < 14> 



INPUT POOL FOR BLOCKS 4 IS: 

C(48 :49, *,50) A(2,*,49) A(l,*,48) 4( 4,47,47) A ( 3 , 46 , 46 )*~ 

ADDR TABL 
ADDRESS 
AODTYPE 
ADDVAL 
ADOCON 

VALUF STACK (TOP AT 133) 

C(GTR 48 49 1 50 ) 

CONT STK <1> <2> <3> <4> <5> <6> <7> <8> <9> <10> <11> <12> <13> <14> 

BLOCK# 12 



ENTRY 



37 



EXEC STAC <1> <2> <3> <4> < 5> <6> <7> <8> <9> <I0> <11> <12> <13> <14> 

(EMPTY) 



8*27 



I LOC 



I 12 



I 00020002 | 



***T ABLE 0 U M P*** AT LOCATION = 27 

EXEC. STAC <1> <2> <3> <4> <5> <6> <7> <8> <9> <10> <11> <12> <13> <14> 



EXCON 

EXTYPE 

EXAOD 

EXVAL# 



N 
LOC 

6 



8*28 



I LOC 



I 13 



I 00020003 I 



***T ABLE D U M P*** AT LOCATION = 28 

EXEC STAC <l> <2> <3> <4> <5> <6> <7> <8> <9> <10> <11> <12> <13> <14> 



EXCON 

EXTYPE 

EXADD 

EXVAL# 



N 
LOC 
2 
0 



N 
LOC 
3 
0 
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TABLE V (CON'T) 



8*29 



I LOO 



I 10 



I 00270000 | 



ABLE 
EXEC STAC <1> 
EXCON N 

EXTYPE LOC 

EXADO 2 

EXVAL# 0 



D U M P*** AT LOCATION = 29 
<2> <3> <4> <5> <6> <7> 

Y 

I NT 
I 

46 



<8> <9> <I0> <U> < I 2> < 1 3> < I4> 



B*30 



I LOC 



i 14 



| 00020004 | 



***T ABLE 
EXEC STAC <1> 



EXCON 

EXTYPE 

EXACD 

EXVAL# 



N 
LOC 

6 



D U M p*** AT LOCATION = 
<2> <3> <4> <5> <6> 



Y 
I NT 
1 

46 



N 
LOC 
4 
0 



30 
<7 > 



<8> <9> <10> <11> < 1 2> <1 3> <U> 



B+3I 



I LOD 



\l 0 



| 00270000 I 



***T A B 

EXEC STAC 

EXCON 

EXTYPE 

EXAOD 

EXVAL# 



. E 


D U M 


<1> 


<2> 


N 


Y 


LOC 


INT 


2 


i 


0 


46 



P*** AT LOCATION = 
<3> <4> <5> <6> 

Y 

1 NT 

2 

47 



31 

<7> 



<8> <9> <10> <U> < 1 2> <1 3> < 1 4> 



B*32 



I ADD 



I 10 



| 00100000 



***T ABLE 



CONSTANTS 


<I> 


<2> 


<3> 


CONSYM 


2 1 


I 3 


5 


CONTYPE 


INT 


INT 


INT 


CONVAL 


46 I 


[47 


52 


CON INT 


2 I 


13 


5 



U M p*** at LOCATION = 
<4> <5> <6> 



32 

<7> 



<8> <9> <10> <ll> < 1 2> < 1 3> < 14> 




NEW EXPRESSION ADDED 
B := C + D; 



VALUE STACK (TOP AT 139) 

C(ADD 46 47 |52) C ( GTR 48 49 1 5 0 > 



EXEC STAC 


<I> <2> 


EXCON 


IN I Y 


EXTYPE 


LOC INT 


EXADD 


2 U 


EXVAL# 


10 52 



<3> <4> <5> <6> <7> <8> <9> <10> <11> <12> <13> <14> 



B+33 0 ISTO 



I 10 | 00280000 | 



***T ABLE 


D U M P**« AT LOCATION = 33 


ADDR TA6L 


<1> 


<2> 


<3> 


<4> 


<5> <6> <7> <8> <9> <10> <11> <1 2> < 1 3> <H> 


ADDRESS 


3 


4 


1 


2 


2 


AODTYPE 


INT 


INT 


INT 


INT 


INT 


ADOVAL 


46 


47 


48 


49 


52 


AOOCON 


1 


2 


0 


0 


3 


EXEC STAC 


<1> 


<2> 


<3> 


<4> 


<5> <6> <7> <8> <9> <I0> <ll> < 1 2> < 1 3> <K> 


EXCON 


Y 










EXTYPE 


INT 










EXAOO 


3 










EXVAU! 


52 










6*34 0 


IDEL 


1 


10 


| OO2A00O0 | 


***T ABLE 


D U M P*** AT LOCATION = 34 


EXEC STAC 
( EMPTY) 


<I> 


<2> 


<3> 


<4> 


<5> <6> <7> <8> <9> <10> <U> < 1 2> <13> <14> 


B+35 0 


1 X I T 


1 


117 


| 0004D01 1 | 
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TABLE V (CON’T) 



* **T A B 


L E 


D U 


M P*** 


AT 


LOCATION = 


35 
















CONT ST K 

BLOCK# 

ENTRY 


<l> 
1 37 


<2> 

iii 


<3> 


<4> 


<5> 


<6> 


<7> 


<3> 


<9> 


<10> 


<ll> 


< I 2> 


<13> 


<!<♦> 


EXEC STAC 
(EMPTY) 


<l> 


<2> 


<3> 


<4> 


<5> 


<6> 


<7> 


<8> 


<9> 


<10> 


<ll> 


<12> 


<13> 


< I4> 



B*36 0 IBRS I |0 

BEFORE THE MEET OPERATION: 

OUTPUT POOL FROM BLOCK# 4 IS: 
C( 48:49, *,50) C( 46 : 47, * , 5 2 ) 



I 002E0000 | 

MEET OPERATION IS NOW PERFORMED USING THE FIRST 
BLOCK ON THE CONTROL LIST 

A( 2f 5 2t 52 ) A(l,*,48) A(4,47,47) A(3,46,46) 



CURRENT POOL FOR BLOCK# 2 IS: 

A(2,*,49) A<1,*,48) A(4,47,47) A(3,46,46) 

CLASS OCCURENCE LIST: * 

ADOR CLASS NUMBER NUMBER OF OCCURRENCES 

1 49 1 

FOUR CLASS NUMBERS 
ARE IN THE OCCURENCE 
LIST 

AFTER PROCESSING SIMPLE VARIABLES: 

CLASS OCCURENCE LIST: 

(EMPTY) __ ^SIMPLE VARIABLES HAVE EXHAUSTED THE 

"CLASS OCCURENCE LIST 




CLASS REFINEMENT TABLE: 



LX 


NEW VALUE# 


CURRENT VALUE# 


1 


53 


49 


2 


43 


48 


3 


47 


47 


4 


46 


46 


AFTER 


PROCESSING ALL 


EXPRESSIONS: 


CLASS 


OCCURENCE LIST: 





(EMPTY) 



INPUT VALUE# 



52 

48 

47 

46 



NEW CLASS NUMBERS ASSIGNED 
ONLY IF CLASS NUMBERS DIFFER 



CLASS REFINEMENT TABLE: 
LOC NEW VALUE# 



53 

48 

47 

46 



CURRENT VALUE# 

49 

48 

47 

46 



INPUT VALUE# 

52 

48 

47 

46 



AFTER PERFORMING THE MEET OPERATION: 

NEW CURRENT POOL/INPUT POOL IS THE SAME AS OLO CURRENT POOL 

BLOCK 02 WILL NOT BE PROCESSED 
BECAUSE ITS CURRENT POOL IS SAME 




***T ABLE 
ADOR TABL 
ADDRESS 
ADDTYPE 
ADOVAL 
A DOC ON 



(EMPTY) 



0 U M P*** AT LOCATION = 36 



<I> 


<2> 


<3> 


<4> 


<5> 


<6> 


<7> 


<8> 


<9> 


<10> 


<I1> 


< 1 2> 


<1 3 > 


3 


4 


1 * 


2 


2 


0 


0 












INT 


INT 


INT 


INT 


I NT 


ADD 


GTR 














46 


47 


48 


49 


52 


52 


50 














l 


2 


10 


0 


3 


0 


0 














<1> 


<2> 


<3> 


<4> 


<5> 


<6> 


<7> 


<8> 


<9> 


<10> 


<ll> 


<12> 


< 1 3> 



CONTROL AT 37. FROM BLK 2 TO BLK 3 (PASS 1) CFA PASSES CONTROL FROM BLOCK 02 

C f 37 0 I ENT I C 1 55 I 00038037 | TO BLOCK 03. 

***T ABLE 0 U M P*** AT LOCATION = 37 
INPUT POOL FOR BLOCK# 3 IS: 

C(48:49,*,50) A(2,*,49l All, *,48) A(4,47,47) A(3, 46,46) 
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